dsh-plugin-durable-subagent

LIMITATIONS

已知限制

- **A linked plugin resolves its imports from its own repository.** `dsh plugin add <path>` records a `link:`, and Node follows the symlink to the plugin's real path, so `@deepseek-ai/*` is resolved from the plugin directory and never from the profile. The local install must therefore carry a complete closure: `npm install` resolves this package's harness peers, while `npm install --legacy-peer-deps` leaves `@deepseek-ai/dsh-tools` without the nine packages it declares as peers, and the profile then fails to boot with `failed to import loader entry durable-subagent (dsh-plugin-durable-subagent): Cannot find package '@deepseek-ai/dsh-scope'`. A published install from npm does not have this problem. - **`cwd` is part of the submission digest.** A retry from a different working directory is a `request-conflict` rather than the first outcome. The default is stable for the life of the harness process; a per-session `cwd` is not yet wired. - **The provider cannot be replay-stable.** `ResolvedSubagentStartRequest` carries no call identity, so only the tool path gets one execution per call. Making the provider path exact needs a durable run identity on the request; that is a harness change. - **`dispose()` stops a run but does not await quiescence.** The orchestrator is a separate process and owns its own teardown, so the run handle cannot observe the child's exit. - **No continuable children and no Agent Teams membership.** `prepareContinuable` is deliberately not implemented: `spawn_teammate` and cold resume need a durable child session this provider does not create. - **No tool filtering, persona, or delegation depth.** The provider reports `outputSchema` only; a request needing another capability is rejected loudly by the subagent service rather than silently ignored. - **`outputSchema` validation is delegated.** `pi-durable-subagents` validates a `report` against the schema it was handed before sealing, so a sealed `data` payload is schema-valid; the plugin does not re-validate it. - **The orchestrator is not supervised.** The plugin neither starts nor restarts `pi-durable-subagents`; it relies on the orchestrator's own lazy start, lock, and idle exit. Running it under `ctx.subprocess` would make harness disposal kill it. - **A failure is per call.** A workflow reports `status: "done"` even when every call inside it failed, and `output`/`error` live on the calls. `summarize()` reads them there; the read-only `status` view alone would call a failed delegation completed.