dsh-subagent-templates

LIMITATIONS

Known limitations

- **No parent/child grouping in the shipped sidebar.** The child is a normal session, so the official workspace tree lists it as its own session rather than nested under the parent. This plugin's own panel is where the grouping shows; the tree is not extended. - **Deleting from the panel leaves the mapping record behind.** The panel performs the shipped archive-with-stop, so the child Session goes and the panel row goes with it, but this plugin's own mapping row survives until the parent agent calls `delete_subagent` for that name. A later call re-archives an already-archived Session, which is a no-op. A Host-side delete reachable from the panel would remove both in one step; it is a client-to-Host call this plugin does not make. - **A background child is stopped by interrupting or deleting it, not by `interrupt_agent`.** That tool authorizes against a target's recorded lineage in the subagent service, which a root-session child has none of. Use `interrupt_subagent`, or — since the child is a normal session — its own stop button. - **The plugin owns the child Agent's lifetime.** A root Session created here is not registered with `ctx.subagents`, so `send_message`, `list_agents`, and the team panel do not see it. Open the child's own tab to talk to it. - **A child that outlived this plugin keeps running with no handle in memory.** A reloaded instance rebuilds the mapping, the parent's tools, and the child's watch, but the `AgentHandle` that created the child died with the previous instance, so `delete_subagent` stops such a child through the shipped archive-with-stop path (the Agent registry answers `workspace/session-stop` by cancelling its turn) rather than by disposing a handle it no longer holds. The Agent object itself stays registered, idle and archived, until the process exits — the residue the shipped panel already leaves for any archived Session. - **No per-call model override.** A call names a template and nothing else, by design; a pool template's route is resolved by the pool, and changing the child's model afterwards is the user's action in its picker. - **A pool template depends on `dsh-llm-quota-retry`.** The pool, its balance scripts, and the allowance marks belong to that plugin: this one only asks it which route a child should start on, and fails the delegation loudly when the service is absent or the pool is undefined. A template with a fixed `provider`/`model` needs nothing from it. - **No structured output.** A template call returns the child's closing text. - **The row's schema owns the shape.** `toolName` cannot be edited from the settings page because a rename needs the row to restart, and a template that states neither a route nor a pool is refused wherever it is written. Everything else about a template is free to change while the row runs. - **Replicated Harness internals.** `lib/harness.js` mirrors shipped files that a bundle cannot import. A Harness upgrade that changes the final-output selection rule or the turn-end vocabulary must be reflected there. The file names its sources. - **The `user` a mid-turn message claims is a rendering decision, not an identity one.** A consumer that tells a human's own words from another agent's by `source.kind` alone now reads a child's mid-turn message as the former. What keeps that bounded today is that those consumers also require an `rpcId`, and only browser prompt admission writes one — a Harness change that dropped that requirement would turn this into a real authority question rather than a naming one. The durable `senderSessionId` on the same source is unaffected. - **The client half has no bundler.** `client.js` is served as one classic script, so it imports nothing, reaches React and the shared primitives through the module system's `require`, and injects its own stylesheet from `--dsw-*` tokens instead of shipping a CSS file. The settings page it registers reads and write