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 |
|---|---|
| Webhook rule runtime for maintainers registering trusted external-event policies that create Workspace Sessions. | package-reference |
@deepseek-ai/dsh-webhook
English | 中文
Summary
dsh-webhook provides the Host ctx.webhookRuntime: a registry for trusted programmatic webhook rules plus the one built-in action, creating an ordinary root Session inside a Web Workspace. The interface stays at register(rule) and dispatch(delivery); provider authentication belongs to adapter packages. Use it when a trusted rule must turn an external event into a new agent Session.
Table of Contents
- Rule interface
- Session request
- Composition
- Model Experience
- Known Limitations and Deferred Work
- Dev Note
Rule interface
WebhookRule<K> has a branded unique id, a provider kind, and run(delivery, signal). A callback may execute arbitrary trusted code and returns either null or one WebhookSessionRequest. Rules of the same kind start independently, and one throw or rejection is logged without starving siblings.
VerifiedWebhookDelivery carries provider kind, configured source id, provider delivery id, normalized lossless JSON, and receipt time. The runtime snapshots and freezes the complete value before sharing it. deliveryId records the provider's identifier only; repeated delivery runs the rules again.
Registration is an effect. Its awaitable disposer first hides the rule, then aborts and drains active callbacks. Callbacks must observe the supplied signal; same-process code that ignores cancellation cannot be forcibly stopped safely.
Session request
WebhookSessionRequest requires workspacePath, title, prompt, agentPreset, and permissionPreset; optional model names an explicit provider/model route plus an output-token cap. An explicit route uses its adapter's reasoning default. Omission captures the complete current deployment selection, including reasoning effort, as the initial Agent options. A recorded Session selection or request then takes precedence; later Web model changes follow the ordinary Session behavior.
The runtime validates presets before mutation, resolves or creates the canonical Workspace, creates an Agent with that Workspace path as SessionHeader.cwd, mounts the agent preset before publication, and attaches the Session before applying permissions, title, and prompt. Failed attachment disposes the unpublished action. A later pre-prompt failure detaches the Workspace and disposes the Agent on a best-effort rollback.
Successful Agent.followup() is the webhook operation's commit point. The message uses source.kind: "webhook" and records the provider, source, delivery, and rule identifiers. The runtime does not wait for idle, flush specially, inspect the reply, or publish completion state; ordinary Agent and Session behavior owns everything afterward.
Composition
Load the runtime on the Web Host plane after Agents, model defaults, agent presets, permission presets, titles, and the Workspace registry. User-authored rule plugins inject webhookRuntime and yield the disposer returned by register() through their own effect.
The GitHub review guide shows a rule module, dedicated ingress port, secret setup, and Workspace routing.
Model Experience
Rule-authored initial prompt
What the model sees
For each matching rule, the model sees exactly the non-empty text returned as WebhookSessionRequest.prompt. The generic runtime adds no private framing; a rule incorporating external text owns its trust labeling. The shipped GitHub example labels selected PR fields as untrusted JSON metadata.
Token effect
One data-dependent user-role message is retained in the new Session and contributes tokens until ordinary compaction replaces or removes that history.
KV Cache effect
The initial prompt begins a new Session, so it establishes rather than invalidates that Session's reusable request prefix.
Known Limitations and Deferred Work
- Process-local fire-and-forget only — a crash loses rule calls that have not admitted a prompt; there is no queue, replay, or retry.
- No built-in deduplication — repeated provider deliveries may create repeated Sessions; rules that need idempotency own it.
- No completion result — HTTP acceptance and rule settlement do not report Agent success, idle, or output.
- Trusted callbacks must cooperate with cancellation — runtime teardown aborts and awaits them but cannot terminate arbitrary same-process code.
- Workspace creation may outlive a failed Session attempt — an empty Workspace is retained because another concurrent caller may already use it.
Dev Note
Working context for maintainers — click to expand
None.