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.
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.
`tool-fs.applyPatchGuard` selects the mutation guards of apply_patch:
`observation` consults the mounted observation policy per operation like
write and edit; `none`, the default, applies hunks unconditionally on
context match alone as the Codex tool does, keeps publishing fs/observed,
and replaces the read-first guidance with a context-matching reminder.
In 2,226 recorded DS-Bench and DeepSWE rollouts with the policy on, read-first
and stale-version refusals were 29–41% of apply_patch failures although hunk
context matching already rejects a divergent file. The recorded apply-patch
scenarios pin `observation`, under which they were captured.
Across 2,226 recorded DS-Bench and DeepSWE rollouts, 14% of apply_patch
calls arrived as {"input": ...} and were rejected for the missing `patch`
property: models trained on the Codex tool send its parameter name
unprompted. The schema now uses `input`; the executor request keeps its
internal `patch` field. Recorded apply-patch sessions, the schema sidecar,
and the catalogs follow.
Takes master's re-measured npm install-layout budget, which covers this
branch's graph, and regenerates the Cordis API, event matrix, client slot,
and tool catalogs on the merged tree.
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.
yudshj