5cf5e0cb76
Deleting the preset a user default names left the setting pointed at an id nothing will ever supply again, and every session created without an explicit pick then failed to start — the delete dialog called it 'new sessions cannot select it', which understates a hard creation error. `remove` now clears the user layer when it named the preset just deleted, exposing the deployment's own default underneath. Storing a default that does not exist YET stays deliberate: the roster is a live directory, so a name absent now may exist by the time a session asks, and `resolve` still reports that case. `agentPreset.select` also leaves the loopback set. It was pinned as a real escalation — one preset mounts the toolset that edits the live runtime — but `session.create` already takes an `agentPreset`, so pinning only the switch left the same capability one method over. The deeper reason is that the capability is not the preset's to grant: the deployment's own default already carries `bash` and the filesystem tools, so any caller that may start a session at all can already run commands as this process. `read`/`write`/`remove` stay pinned on their own footing — those touch files, not sessions.
7 lines
432 B
YAML
7 lines
432 B
YAML
# Bilingual-pair consistency record (docs/i18n/README.md): the git blob hash of each
|
|
# side as of the last confirmed-consistent state. Both languages carry equal authority;
|
|
# after editing either side, bring the other along and re-record with:
|
|
# pnpm run verify-translation-pairing --write packages/host/apiproxy/README.md
|
|
README.md: a18a4e4c123d70b44e2104d746dd416bacac8210
|
|
README.zh.md: 177af927aa1b0dc9c8ce49f4a0e8357cbb277760
|