Dudu-0223
ff563d07e0
Models coordinate subagents through send_message, interrupt_agent, list_agents,
and Team task owners, but every one of those addressed a member by a
36-character Session id. Each new child now has a name, unique among its
creator's children, recorded as a field of the subagent/catalog entry the
creator already appends (payload version 3).
The Session id stays the only execution identity for routing, authorization,
persistence, task ownership, and navigation. A name is a model-facing
reference: 1-32 lower-case letters, digits, or hyphens starting with a letter,
never `lead`, so a UUID never parses as one. Omission selects the first free
`agent-N`; an explicit duplicate or invalid name fails before startup. The
creator reserves the name synchronously at admission and releases it when the
catalog entry commits or startup fails, so no second write, rollback protocol,
or optional naming service exists.
The root is `lead`, and a descendant's full name is its path from the root
without a `lead/` prefix, such as `reviewer/checker`. Sibling-unique segments
make full names tree-unique without a root registry, and cold resume rebuilds
a member's path from the catalogs along its creation chain. A member below an
unnamed historical creator keeps its Session id as its name. resolveName()
reads only the catalogs along the path and grants no authority.
Tools, runtime-authored text, and the Web client consume names: delegation
takes an optional name and returns { kind, subagentId, name }; send_message and
interrupt_agent take `agent`; list_agents rows carry name, status, and
description; Team task results report the owner's name while storage keeps
ownerId; identity runtime context, message framing, and settlement notices use
full names. Recorded sessions, CLI and Web expectations, the Python runtime
snapshots, bilingual docs, an upgrade guide, and an Agent Note follow.
description, kind
| description | kind |
|---|---|
| Ready-made dsh profile bundles for the shared core, browser GUI, one-shot task, ACP, and SDK application surfaces. | package-group |
bundle/ — profile plugin bundles
English | 中文
Summary
This group maps the installable patch layers used by dsh --profile. Each package declares dsh.bundle.patch; the launcher stacks those patch documents to assemble a named profile. The web, headless, acp, and sdk profiles build on dsh-base, while sdk-minimal supplies its complete tree in one bundle. Domain packages can declare additional layers outside this directory.
Table of Contents
Packages
| Package | Role | ctx key |
|---|---|---|
base |
Shared core for base-backed profiles | — (patch only) |
acp-app |
Automation-only ACP stdio application over base | mounts the ACP bridge |
web-app |
Browser application layer over base | mounts Web rows |
headless |
One-shot command-line task application over base | headless-runner |
sdk-app |
SDK JSON-RPC stdio application over base | mounts the SDK server |
sdk-minimal |
Standalone minimal SDK application without base or Web | — (complete patch tree) |
In-box bundles resolve from the dsh installation; out-of-tree bundles install into a profile through dsh plugin --profile <name> add <package>.
Related documentation
- dsh app — the
dshcommand that starts a profile. - app-boot — how profiles are resolved, layered, and customized.
- Profile plugin bundles note — the profile and bundle composition design.
- Generated composition graph — the exact composition each shipped profile uses.
Dev Note
None.