`tool-bash` resolves the background-task registry with `ctx.get('tasks')`,
and it sits at the preset's top level. The registry sat inside an
entry-local `isolate: { tasks: true }` realm, which is invisible to every
sibling row outside it, while the Web surface disabled the host row — so
both lookups missed and every `run_in_background` call answered
"background tasks unavailable" with `task_output`, `task_list`, and
`task_kill` still listed in the catalog. `task_list` returning
"(no background tasks)" is what made the outage read as an empty queue
rather than a severed producer.
That is the `goals` criterion read from inside the preset: a Service a row
outside its realm READS belongs to the plane both can see. `tasks` already
keys access by owning agent (`assertAccess` compares `task.owner.id`) and
mints an independent token per `attachSurface` call, so one host instance
serves every session exactly as before presets — the per-preset-standing-mounts
note records that sharing `tasks-local` is a return to its design.
`minimal` mounts no `tool-tasks`, and the `start()` control-surface gate is
a service-wide set that another preset's controls would open for it, so its
`tool-bash` disables `run_in_background` and drops the parameter from the
schema.
Fixes#2141
`cordis` and `code` are full copies of `standard`, so each carried its own
copy of the goals group the Gateway cannot reach through. Same change, same
reason.
`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.
Code Mode was a deployment-wide field on the host `tools` row: a
deployment ran every session that way or none. The obvious product
shape — 代码模式 beside 标准/极简/创造 in the preset picker — had
nothing to hang on.
The registry itself cannot move into a preset; the agent loop's
scheduler, the api-proxy's presenters, and every tool plugin are its
consumers. So split the registry from its projection: `presentAs(mode)`
writes one cell on the calling agent's scope layer, exactly as
`restrict()` does, and the three reads that decided presentation take
that scope's mode instead of the service's. The config `mode` becomes
the default agents shadow rather than a process-wide fact.
Two consequences are load-bearing. `run_code` now enters a view only
for scopes whose own mode presents it — a native agent must not find it
dispatchable because another agent in the process does — and the
reserved name holds whatever the configured mode, since any agent may
select a code mode later.
`dsh-agent-tool-mode` is the row a preset carries to declare this. A
code mode waits for the host's `codeRuntime` rather than assuming it,
so a runtime-less deployment fails the preset at mount, naming the
row, instead of at the session's first request.
The shipped `code` preset is `standard` plus that row, ordered second.
