fix(agent-presets): keep the code preset on one plane, and check that
`code` still carried `bash-env` behind its own `isolate` realm and its own `tool-subagent-report` row — the two the other three presets had already given back to the host. It was added a layer above the fix, so the rebase carried it forward untouched, and the shipped deployment ran a preset whose sessions get no `DSH_WEB_URL` in their shell and hand every subagent a second `report` registration on the host registry. Nothing caught it. A tool-catalog assertion cannot: neither row contributes a tool. The web lane cannot: no scenario composes `code` beside another preset, which is when the second `report` throws. The presets are near-copies of one another, so "fixed in three of four" is the shape this failure takes, and it will take it again. So the invariant is checked rather than described. `verify-cordis-config` now rejects any shipped preset row that is also active on the host plane, which is the property both defects violated: a row active on both planes is mounted once per process and once per session, and what that costs depends on the row — a provider behind an `isolate` realm shadows the host's for its own consumers, so a host contributor reaches nobody; a row registering into a host singleton registers once per live session, so the second collides.
This commit is contained in:
@@ -41,22 +41,15 @@
|
||||
|
||||
# ── shell ───────────────────────────────────────────────────────────────────
|
||||
|
||||
# `tool-bash` reads as a tool but provides the `bashEnv` service, so it needs a
|
||||
# realm like any other provider. The executor behind it (`bash-sandbox`) stays
|
||||
# in the host composition, where the sandbox policy owns it.
|
||||
- id: shell
|
||||
name: cordis:group
|
||||
group: true
|
||||
isolate:
|
||||
bashEnv: true
|
||||
config:
|
||||
# The registry and its consumer share the realm: a consumer left outside
|
||||
# would resolve the host's `bashEnv`, which this plane no longer provides.
|
||||
- id: bash-env
|
||||
name: '@deepseek-ai/dsh-bash-env'
|
||||
|
||||
- id: tool-bash
|
||||
name: '@deepseek-ai/dsh-tool-bash'
|
||||
# `bash-env` stays in the HOST composition: `apps/cli/src/web.ts` injects it to
|
||||
# publish `DSH_WEB_URL`/`DSH_WEB_MODE`, and a host row that injects a service is
|
||||
# the criterion for host-plane ownership — injection resolves before any session
|
||||
# exists, so there is no agent to key by. Behind a preset realm those variables
|
||||
# never reached the model's shell at all. `tool-bash` consumes the host registry
|
||||
# from here; the executor behind it (`bash-sandbox`) is host-plane too, where the
|
||||
# sandbox policy owns it.
|
||||
- id: tool-bash
|
||||
name: '@deepseek-ai/dsh-tool-bash'
|
||||
|
||||
# ── filesystem ──────────────────────────────────────────────────────────────
|
||||
|
||||
@@ -217,9 +210,6 @@
|
||||
toolName: subagent_fork
|
||||
backgroundMode: continuable
|
||||
|
||||
- id: tool-subagent-report
|
||||
name: '@deepseek-ai/dsh-tool-subagent-report'
|
||||
|
||||
- id: workflow-workerthread
|
||||
name: '@deepseek-ai/dsh-workflow-workerthread'
|
||||
config:
|
||||
|
||||
Reference in New Issue
Block a user