Integrate PR #7774 with one-shot code guidance and matching snapshots. Cover distinct nested call IDs sharing a root and concurrent model calls with pending input.
Review round on the naming change.
`resolveName` now distinguishes an address from a Session id: a
slash-separated address never is one, so an unmatched path fails with
AGENT_NAME_NOT_FOUND instead of reaching member lookup as an unknown id,
while a single token keeps the Session-id fallback. Path resolution also
treats external and unknown children as leaves, so a name below an external
run reports the same clear failure instead of surfacing a session-query error
for an identity that owns no local Session.
Native V4 admission rejects a repeated sibling name in own catalog facts,
symmetrically with its duplicate-child check, so a log that would make name
lookup ambiguous fails before any member is resolved.
`SiblingNameReservations.release()` checks that it still owns the map entry,
so a stale or repeated release cannot drop a newer reservation for the same
creator.
`list_agents` explains corrupt, unsupported, and unavailable: they report that
the row's own descendants could not be read, and the row remains a member the
caller can message. The earlier wording restricted messaging to running or
inactive rows, which excluded addressable members.
`isAgentName` stays module-local; the package entry exports only
ROOT_AGENT_NAME, matching its current callers.
Package READMEs, the subsystem page, the Agent Note, and the generated API
catalogue follow; recorded-session, CLI, and Web expectations are refreshed.
The discovery tool presented itself as the place to inspect options before
selecting a child route, and rejected every provider or model outside the
Session's authorized routes, including providers that do not exist. A model
that skipped the no-argument call therefore had no way to learn the correct
ids or that omission was legal, and repeated identical denials.
Say that queries exist to override the child route, that omitting both route
fields inherits the parent route, that a field is omitted rather than sent
empty, and, in each optional route field, that omitting it inherits the
parent value.
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.
Takes master's re-recorded plan-review, creation-recommendations, and
plugin-recommendations scenarios from the base and refreshes their headers
and schema sidecar for the enabled apply_patch tool.
Evaluation on the shipped compositions decided the defaults: the `dsh-base`
`tool-fs` row and the Web `standard` preset enable apply_patch, keeping the
SDK and Desktop `standard` tool sets equal (the SDK PTC overlay keeps the
base row while the Desktop PTC preset lists its own, which the parity
exceptions record); the `fs-observation-policy` row ships `disabled: true`,
so write, edit, and apply_patch mutate unconditionally in every profile, and
the package is classified as an optional product package.
The write and edit guidance stops citing the policy as the default and the
apply_patch guidance asks for enough hunk context instead of a prior read.
The two recordings that capture a policy refusal re-enable the row through a
per-scenario runtime.cordis.yml; the fixed-budget compaction scenarios pin
`applyPatch: false` so their recorded thresholds hold; every other sidecar
and recorded header follows. An upgrade guide records the default change.
This pull request lands the tool; switching the shipped defaults is a
separate pull request stacked on it. Every shipped `tool-fs` row states
`applyPatch: false`, the `fs-observation-policy` row stays mounted, the
write, edit, and apply_patch guidance names the policy, and every recorded
expectation outside the apply-patch scenarios returns to the master
baseline. The upgrade guide, the parity exception, and the optional
classification of the policy package move to the stacked change.
Evaluation on the shipped Web composition decided the defaults: the
`fs-observation-policy` row in dsh-base ships `disabled: true`, so write,
edit, and apply_patch mutate unconditionally in every profile; the Web
`standard` preset lists apply_patch; and the tool-fs `applyPatchGuard` switch
is gone, apply_patch always consulting the fs/* intent waterfalls like the
other mutating tools.
The write and edit guidance stops citing the policy as the default, and the
apply_patch guidance asks for enough hunk context instead of a prior read.
The two recordings that capture a policy refusal (fs-policy-reject and
apply-patch-rejected) re-enable the row through a per-scenario
runtime.cordis.yml; every other sidecar follows the prompt change, and the
Web standard-preset recordings gain the apply_patch schema. An upgrade guide
records the default change.
89 recorded system prompts carry the restored sentence; the two pinned
historical sidecars keep their recorded text. The package README fence is
updated in both languages.
The blocking ask_user_question description did not explain that an answer
item with empty selected and no custom is a user skip, so models re-asked
the same question after the user clicked Skip.
Refs #7134
* feat(experimental): ship the two card experiments as one Personalized recommendations bundle
@deepseek-ai/dsh-personalized-recommendations inserts the action card
service, its browser half, Personalized pages and Plugin recommendations
with their card bodies under the existing row ids. As the only layer that
declares those ids, the Plugins page addresses and switches each row,
including the two shared card rows that were read-only while two bundles
inserted them.
The two experiment packages stop being bundles; the new bundle takes their
place in the official lists and the dsh installation, with the personalized
pages icon, localized title and description, and a feature preview of both
cards. The two feature rows describe what they do on the bundle page.
* fix(experimental): drop the model reason line from plugin recommendation cards
The reason follows the language of the user's question while the catalog
description below it follows the interface language, so the two lines could
differ in language and largely repeat each other; the answer already gives
the reason. The card keeps the catalog title and description, both in the
interface language, as its details target.
* test(web): refresh the card fixtures for the Personalized recommendations bundle
Both card replays enable the new bundle, so each Session lists both card
skills, and each skill's catalog lists Personalized recommendations in place
of the two former bundles. The plugin card goldens lose the reason line.
---------
Co-authored-by: ZiyaZhang <[email protected]>
The plugin skill's catalog lists every official plugin's title and
description in the eight shipped languages, and the page skill's catalog
lists the plugin recommendations entry with its new translations.
The two packages keep their directories under packages/experimental and are
registered as experimental name exceptions:
- @deepseek-ai/dsh-plugin-recommendations
- @deepseek-ai/dsh-client-ui-plugin-recommendations
Loader row ids, the Remote service name, locale namespaces and the
enable_official_plugin action are unchanged. Generated catalogs are
regenerated, and both card Web fixtures record the renamed bundle in their
skills' plugin catalogs.
Takes the card packages' new names and master up to e115cc98d65. The plugin
recommendation packages and their bundle rows now name
@deepseek-ai/dsh-action-cards and @deepseek-ai/dsh-client-ui-action-cards;
generated catalogs are regenerated, and both card Web fixtures record the
renamed bundles in their skills' plugin catalogs.
Dudu-0223