mirror of
https://github.com/deepseek-ai/deepseek-harness
synced 2026-08-15 21:04:50 +00:00
59e759ce13
One host registry serves every composition in the process, so its two service-wide collections answered per-owner questions process-wide. `start()` asked only whether SOME surface was attached, so an agent whose own composition loads no `tool-tasks` could start work it has no tool to collect or stop as soon as any other preset attached one — and the answer changed depending on which sessions happened to be open. `settle()` walked every registered listener, so a task settling without a waiter injected one completion notice per mounted preset into the same owner. Both collections now sit in `ScopedLayers`, the layered-registry primitive `tools` and `skills` already use: a registration files into its registering context's scope, and a read unions the global layer with the owner's scope chain. A surface or listener registered from an unscoped context lands in the global layer and serves every owner, which is exactly the host-plane composition's own controls, so the TUI path is unchanged without a special case. This supersedes the consumer-side filter in the previous commit. That filter produced the right notices but sat in the wrong layer: it left the `start()` gate process-wide, it could not be enforced against a producer that resolves the registry directly, and it made a Consumer carry scope knowledge that the other layered registries keep in the registry. `tool-tasks` is scope-agnostic again and the `dsh-scope` edge moves to `tasks-local`. `start()`'s refusal is now owner-relative, so its model-visible text names the agent rather than the process. The shipped `minimal` preset keeps `enableRunInBackground: false`, no longer as the safety boundary — the registry owns that now — but so an agent that could never collect a task is not offered the parameter at all. Refs #2141
bash/ — bash capability family
English | 中文
The capability family spans the canonical executor seam, its implementations, the shared shell environment, and the model-facing tools. All are product packages.
| Package | Role | ctx key |
|---|---|---|
bash/ |
Defines the executor contract shared by Service providers and Consumers. | ctx.bash |
bash-local/ |
Executes commands through the local subprocess service. |
(registers ctx.bash) |
bash-sandbox/ |
Applies the configured sandbox backend before local execution. |
(registers ctx.bash) |
pwsh-local/ |
Executes PowerShell commands with Windows-specific process behavior. | (registers ctx.bash) |
bash-env/ |
Provides the managed DSH_* environment shared by shell tools. |
ctx.bashEnv |
tool-bash/ |
Exposes Bash execution and background-task integration to the model. | (registers on ctx.tools) |
tool-pwsh/ |
Exposes PowerShell execution to the model. | (registers on ctx.tools) |
A leaf cordis.yml selects one executor implementation and the model-facing tools it needs. A sandboxed composition also selects a ctx.sandbox provider; the ACP example shows one complete wiring.
The subsystem reference — request/spec vocabulary, results, background processes, the service, and events — is docs/subsystems/bash.md.