master now rejects the @deepseek-ai/dsh-experimental- prefix for new
experimental packages, so the unreleased sidebar terminal backend becomes
@deepseek-ai/dsh-terminal-panel with plugin name terminal-panel, and its
directory joins EXPERIMENTAL_PACKAGE_NAME_EXCEPTIONS. The terminal bundle,
root devDependencies, generators, catalogs, snapshot composition and
upgrade guide use the new name; the hand-written tsconfig alias gives way
to the generated one.
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.
A new Agent Note owns the shipped defaults and the original apply_patch note
keeps its opt-in decision with a supersession link; the policy README, the
tool-catalog note, the filesystem page, and the fs group README state the
current defaults without evaluation figures. The PTC overlay sets
`applyPatch: false` so the SDK and Desktop PTC tool sets match without a
parity exception; the fixed-budget compaction scenarios pin the tool set in
their live patches too; the apply-patch composition drops its no-op override.
The upgrade guide scopes the change to base-backed profiles, the README
refusal example is one every composition can produce, the integration suite
names its deployments by guard, and the keyless SDK smoke edits a file the
model never read through the shipped profile.
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.
Resolves the headless snapshot runner (keeps both the readonly-patch-directory
and cua-script-guidance workspace setups), regenerates the client slot and tool
catalogs with their pairing record, adds the apply_patch tool title to the five
locales master introduced, and refreshes the apply-patch system-prompt pin for
master's subagent guidance change.
`tool-fs.applyPatch` now defaults to false instead of deriving from
`write && edit`, so every shipped composition keeps the model request it
had before the tool existed. The `tool-fs` rows that enable `edit`
(dsh-base and the Web standard, ptc, and cordis presets) state
`applyPatch: false` explicitly; changing that one line adds the tool.
The apply-patch snapshot composition enables the switch, the tool catalog
mounts tool-fs with it on so the schema stays documented, and every other
recorded expectation returns to the master baseline.
* 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]>
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.
The four packages keep their directories under packages/experimental and
are registered as experimental name exceptions:
- @deepseek-ai/dsh-action-cards
- @deepseek-ai/dsh-client-ui-action-cards
- @deepseek-ai/dsh-creation-recommendations
- @deepseek-ai/dsh-client-ui-creation-recommendations
Loader row ids, plugin record names, message source kinds, the Remote
service name and locale namespaces are unchanged. Generated catalogs are
regenerated, and the page card Web fixture records the renamed bundle in
the skill's plugin catalog.
Plugin recommendations now proposes through the shared propose_action tool
instead of a dsh-action answer block. The Host registers the
enable_official_plugin kind with the action card service: the
official-plugins skill, details holding the plugin name, the Enable verb
with global access, and the enabled, already-enabled and failed phases,
whose data carries the application outcome and the management error code.
The package drops its own projection, Remote act, status notice and
persisted record; it keeps the describe Remote for card text. The bundle
inserts the shared card rows beside its own, as Personalized pages does.
The browser half registers a card body in the shared frame that keeps the
catalog text cache, the reserved loading lines, the single details target
and the Enable and Not now footer. The skill's submission section now asks
for one propose_action call.
action-cards owns the propose_action tool, the actionCards projection of
proposals and decisions, the act Remote and the card status notice; card
kinds register an action name, skill, details schema, verbs and handler.
The tool is admitted per Agent only after a registered kind's skill loads.
client-ui-action-cards draws the card frame below the completed answer,
lets kinds register a body per action and adds the propose_action
process row.
The proposal is a fenced dsh-action JSON object at the end of the final
answer instead of a suggest_action tool call. The projection reads the
last valid block of an assistant message, keeps one card per turn, and
marks a proposal written while queuedMessageLimit user messages are
queued as suppressed; the chat hides dsh- fences from rendered answers.
The Web replay fixture, tool catalog and READMEs follow the toolless
mechanism.
Follow the tool executor refactor: the tool/ptc-dispatch event type now comes
from dsh-tool-executor-ptc, and the tests invoke tools through dsh-tool-testkit.
Regenerate the doc graphs, tool catalog and persistence schema after the merge
and re-record their translation pairing.
Drop the preflight sandbox fence. It derived writable roots in the local
process, so under the SSH provider it threw on remote additionalWritableRoots
and compared remote targets against local temp roots; write and edit never
fenced in the tool layer. The provider now refuses a denied operation at
commit, and a commit whose first operation failed without any change rejects
like a preflight refusal so the sandbox escalation path keeps its error code.
Classify FS_ABORTED as unknown: a cancelled remote request rejects while the
provider may still be writing, so no stat comparison can settle it. Document
that a cancelled call receives the registry's abort result like every tool.
Store no diff for creations, matching write, and bound the move source basis
by diffBasisMaxBytes so persisted metadata never holds whole files;
FsMoveOutcome.sourceBefore becomes nullable. Omit deletions from the call
preview and from result diffs without a basis instead of rendering them as
empty creations, and count distinct files in the preview title.
Reject a NUL byte beyond the read sampling window in preflight, name targets
by display path in atomic-write diagnostics, align the apply_patch guidance
with the edit wording and mention delete and move, read the stopped flag and
applied diffs tool-agnostically in the client models, skip the permission-bit
snapshot under root, list fs/delete-intent in the tool catalog, and refresh
the fs-patch description, group README, fs-sandbox summary, and ui-tool README.
Yichen Jiang