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 fork subagent backend for users and maintainers choosing, configuring, or debugging children seeded with the parent's completed turns. | package-reference |
@deepseek-ai/dsh-subagent-fork-in-process
English | 中文
Summary
dsh-subagent-fork-in-process is an in-process subagent backend that seeds each child with the parent's completed conversation turns: the child sees every finished turn and none of the in-flight one, so follow-up work builds on the conversation without duplicating it. A delegation tool reaches it under the fork provider name, and its behavior matches the spawn backend except for the session seed. Choose it when a subtask continues this conversation; choose spawn when the child must stand alone. The seed is a one-time snapshot taken at fork time: later parent turns never reach the child.
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 when delegated work must build on the parent's conversation. The common path mirrors spawn: load the subagent service and this backend, then point a delegation tool such as dsh-tool-subagent at the fork provider.
When to choose it
Choose fork when the child needs the conversation's completed turns — a follow-up analysis, a review, a continuation. Choose spawn when the child should start clean, or an out-of-process backend when the child must not share this process. The seed carries conversation history only: the child still gets a fresh tool scope and none of the parent's authority.
Seed boundary
The seed ends at the parent's last completed turn. A parent's current tool-calling turn is still open when a subagent starts, so that in-flight turn is never included; before the first completed turn the seed is empty and the child behaves like a fresh spawn.
Minimal configuration
Load the subagent service and this backend, then configure a delegation tool. This composition exposes a subagent tool backed by fork:
- name: '@deepseek-ai/dsh-subagent'
- name: '@deepseek-ai/dsh-subagent-fork-in-process'
- name: '@deepseek-ai/dsh-tool-subagent'
config:
provider: fork
| Field | Default | Meaning |
|---|---|---|
providerName |
fork |
Provider name registered on ctx.subagents |
The generated configuration catalog is the exhaustive source for every accepted field and its JSDoc.
What a fork 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.
Understand the implementation
Implementation internals — click to expand
This section explains the design decisions behind the backend and where the behavior in Use this package comes from.
Design concept
This backend supplies the balanced completed-turn prefix of the parent log as the child session seed. The subagent service records the inherited range so results contain only the child’s own output.
Source map
| File | Role |
|---|---|
src/index.ts |
Provider registration: prefix computation, Config schema, capability declaration |
Run flow
prepareContinuable() captures the parent’s completed-turn prefix once at creation. startActivation() creates the child with that seed, and the subagent service composes the inherited preset and optional structured output. The provider advertises agent options, output, and depth capabilities; independent preset selection is unsupported.
Lifecycle binding
The delegation tool creates a background activation and returns the child's name. Parent and child share the same messaging tool definitions and ordering; the parent's name in identity runtime context and the return guidance in the initial task both follow inherited history. Workflows await results with caller delivery and send no completion notice to the parent.
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 the design evidence for preserving the inherited request prefix.
- Subagent subsystem — start requests, results, provider contract, and in-process depth and seed.
- dsh-subagent-spawn-in-process — the fresh-child sibling backend.
- dsh-tool-subagent — the model-facing delegation tool that reaches this provider.
- Generated configuration catalog — every accepted config field and its source declaration.
- Forked children preserve the parent request prefix — why continuable fork preserves the inherited request prefix.
Model Experience
Child-agent history and envelope
What the model sees
The child receives the parent's balanced completed-turn prefix, then the new task content verbatim. It joins the parent's preset revision, which supplies persona and tools. Parent agent-local restrictions are not copied. An optional structured-output request adds a child-only tool; the parent's current in-flight turn is excluded.
Token effect
Forking duplicates retained completed history into the child's request, which then accumulates its own tokens independently. A first-turn fork has no inherited history.
KV Cache effect
The child may reuse the inherited byte-identical prefix under the same provider and model. Structured output, generated-SDK, route changes, or historical descriptor overrides on cold resume can invalidate reuse before inherited history; later child history is append-only. Continuable messaging adds no child-only system-prompt section or tool schema; the parent id and return guidance follow inherited history in the initial user task (cache-preserving fork Agent Note).
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; the inherited prefix and internal work remain in the child session.
Token effect
Parent input grows by one data-dependent final 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.
- The seed is a one-time snapshot — the child sees the parent's completed turns as of the fork and nothing the parent logs afterwards; there is no live context sharing.
- Prefix reuse depends on matching request inputs — parent and child messaging definitions match byte for byte; structured output, generated-SDK, route changes, or restored historical overrides can still break equality. Rationale: the cache-preserving fork Agent Note.
- Shipped fork tools do not expose child LLM route selection — they inherit the parent's provider and model so the copied history remains eligible for KV Cache reuse. Route selection stays disabled until a change can preserve reuse or expose a bounded recomputation cost.
Dev Note
Working context for maintainers — click to expand
None.