Tianyi Cui
605587e79c
Add a second axis to every RFC — its class (feature, bug-fix,
simplification, architecture, process, testing) — encoded in the path
as docs/rfc/{lifecycle}/{class}/file.md. The folder is the label, so
the closed set is enforced by structure rather than a parsed field.
Two new doc-sync gates back it:
- verify-rfc-classification: every RFC sits in a valid class folder and
the README index lists it under the matching lifecycle→class heading.
- verify-doc-refs: every docs/*.md path cited in a packages|examples TS
comment resolves — closes a drift class verify-md-links can't see, and
catches the four comment refs this reorg moved.
The README gains a Classification section explaining the taxonomy and
per-class index sub-sections. A self-referential process RFC records why
the scheme is path-encoded and gated.
3.4 KiB
RFC: Capability seams — interface / implementation / consumer split
Status: implemented (accepted 2026-06-13)
Context
The harness has swappable capabilities — bash execution today, sandboxed/remote executors and alternative model providers tomorrow. A capability has three concerns that change at different rates and for different reasons: the contract (what the capability is), the implementation (how it runs), and the consumer surface (what the model and other plugins program against). Bundling them in one package couples those rates of change — swapping a local executor for a sandboxed one would churn the tool schemas the model sees, even though the model-facing contract never changed.
This is distinct from "who provides vs. needs a capability at runtime", which Cordis already answers with services + inject (a provider registers ctx.bash; a consumer declares inject: ['bash'] and its fiber pends until the service exists). That mechanism is necessary but doesn't dictate package boundaries; this RFC does.
Decision
A swappable capability is three packages:
- Interface — an abstract service + the vocabulary types, owning the
ctx.<key>and depending only on cordis (e.g.dsh-bash:BashExecutor,BashRunResult,BashTask). - Implementation — a concrete subclass loaded as a plugin (e.g.
dsh-bash-local: subprocesses, process-group kills, spill-file truncation). Sandboxed/remote backends are sibling packages implementing the same interface. - Consumer — what the model and plugins see (e.g.
dsh-tool-bash: thebash/bash_output/bash_killtool schemas). Consumersinjectthe interface key and never import implementation types.
Implementation and consumer then evolve independently: a sandboxed executor replaces dsh-bash-local without touching a tool schema.
Alternatives considered: one combined package — rejected because it recouples the three rates of change the split exists to separate (the whole point). @cordisjs/plugin-capability — a different axis entirely: it is a permission/capability-security service (named permissions with inheritance, tested against a session via ctx.capability.test), a candidate for the deferred permissions/sandbox work on the tools/execute veto seam, NOT a mechanism for swapping implementations. Confusing the two ("capability") is the trap this RFC names.
The split is not mandatory when the parts are genuinely one concern: the LLM seam folds interface + consumer into dsh-llm (the consumer is the loop itself, not a swappable schema surface) with adapters as the implementation packages. Don't split preemptively — a capability with one conceivable implementation and one consumer stays one package until a second appears.
Consequences
More packages and more boilerplate per capability (a package.json/tsconfig/README trio, the inject wiring). Bought: implementations and consumers ship and version independently, and a new backend never risks the model-facing contract. The rule is documented in AGENTS.md § Conventions ("Capability seams are three packages") and architecture.md § "Capability seams"; the bash trio is the reference template. When to fold vs. split is a judgment call the architecture doc spells out — this RFC records why the default is to split.