39b3db4b9c
- AGENTS.md Commands: fix typecheck/build descriptions; add lint, lint:fix, test:coverage, knip, publint, hygiene (were undocumented). - Drop the bare `yarn demo` for explicit `demo:echo` + `demo:coding`; update README, examples READMEs (and document coding-agent in examples/README). - New cookbook guide: adding-a-vendored-package.md (the missing "add" half of vendor/README's update-only procedure). - architecture.md: add a table-of-contents and extract the Extension cookbook to docs/cookbook/extension-cookbook.md (link-preserving); drop the completed "restructure this document" TODO. - ADR 0009 (capability seams) + 0010 (twin LLM adapters), and a "when to write an ADR" standard in adr/README. - Add a committed dsh-code-review skill under .agents/skills, exposed to Claude Code via a tracked .claude/skills symlink (gitignore carve-out).
2.8 KiB
ADR 0010: Two LLM adapters as a design-verification twin
Status: accepted (2026-06-13)
Context
dsh-llm owns a provider-neutral streaming vocabulary — the StreamChunk protocol (block-start, text-delta, reasoning-delta, tool-call-delta, block-end, usage, finish) and the content-block types (ADR 0004). A vocabulary defined against a single adapter risks baking that adapter's quirks into the "neutral" contract: anything the one implementation happens to do becomes the de-facto spec, and the abstraction is unverified until a second provider arrives — by which point the leak is expensive to fix.
Decision
Ship two adapters against the one contract from the start, deliberately built on different internals:
dsh-llm-deepseek— hand-rolledfetch+ SSE parsing against the DeepSeek API.dsh-llm-pi-ai— the same endpoint through the@earendil-works/pi-ailibrary (its own event vocabulary).
The rule they enforce: anything the StreamChunk vocabulary cannot express for BOTH implementations is a core-vocabulary bug, caught immediately rather than at the next provider. The pair pinned down conventions now documented on StreamChunk in dsh-llm/src/types.ts: usage emitted before finish, nothing after finish, tool-call arguments as raw JSON strings end-to-end, and the two sanctioned error paths (throw from stream() or end with finish {kind:'error'|'aborted'}) that a consumer must handle on both sides — a divergence the library-backed adapter surfaced that a single hand-rolled adapter would have hidden.
Alternatives considered: a single adapter — less code and half the e2e cost, but leaves the "provider-neutral" claim unverified; the vocabulary would encode DeepSeek-via-fetch assumptions silently. A mock second adapter — cheaper but doesn't exercise a real provider's wire quirks, so it proves little. The twin is real-on-real.
Consequences
Double the adapter maintenance and double the key-gated e2e surface (both adapters cover V4 Flash and Pro across representative thinking/effort modes). Bought: a continuously-verified neutrality guarantee for the most leak-prone abstraction in the codebase, and a worked second example for adapter authors. The two share the core Config shape (apiKey/baseURL/models) so a deployment swaps mostly one line, but the reasoning knob differs — dsh-llm-deepseek takes thinking/reasoningEffort, dsh-llm-pi-ai takes a single reasoning level — so a swap translates that field. If the maintenance cost ever outweighs the verification value (e.g. once conformance tests from RFC 004 cover the contract mechanically), retiring the twin to a single adapter + the conformance kit would be a new ADR superseding this one.