Coder/deepseek-harness
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Merge branch 'feat/acp-1-max-tokens-turn-end' into feat/acp-2-bridge

Browse Source
This commit is contained in:
Tianyi Cui
2026-06-17 15:20:36 +08:00
parent c2f8af30da 977c23d31f
commit a9d5a5ba68
17 changed files with 906 additions and 40 deletions
Download Patch File Download Diff File Expand all files Collapse all files

12
docs/architecture.md
View File

@@ -64,17 +64,7 @@ Swappable capabilities are split into **three packages** so each part evolves in
The LLM seam has the same topology folded differently: `dsh-llm` carries the interface (`LlmAdapter`) AND the consumer surface (`ctx.llm.stream()`), with adapters as implementation packages — there the consumer is the loop itself, not a swappable schema surface. Use the full three-package split when the consumer is independently replaceable; keep interface + consumer together when they are one concern. Don't split preemptively: a capability with one conceivable implementation and one consumer stays one package until proven otherwise.
> **"Capability" — two unrelated meanings.** (1) The *seam pattern* above
> ("one plugin provides a capability, another needs it") is realized by
> plain Cordis **services + `inject`**: a provider registers a service
> (`ctx.bash`, declared in `interface Context`); a consumer declares
> `inject: ['bash']` and its fiber stays pending until the service exists,
> tearing down via HMR if it later vanishes. No extra library is needed.
> (2) `@cordisjs/plugin-capability` is a different axis entirely — a
> **permission/capability-security** service (named permissions with
> inheritance/dependency, tested against a session via `ctx.capability.test`).
> It is a candidate for the deferred permissions/sandbox work (the
> `tools/execute` veto seam), NOT a mechanism for swapping implementations.
> **"Capability" — two unrelated meanings.** (1) The *seam pattern* above ("one plugin provides a capability, another needs it") is realized by plain Cordis **services + `inject`**: a provider registers a service (`ctx.bash`, declared in `interface Context`); a consumer declares `inject: ['bash']` and its fiber stays pending until the service exists, tearing down via HMR if it later vanishes. No extra library is needed. (2) `@cordisjs/plugin-capability` is a different axis entirely — a **permission/capability-security** service (named permissions with inheritance/dependency, tested against a session via `ctx.capability.test`). It is a candidate for the deferred permissions/sandbox work (the `tools/execute` veto seam), NOT a mechanism for swapping implementations.
## The vocabulary (dsh-llm)