Files
deepseek-harness/docs/rfc/implemented/2026-06-13-twin-llm-adapters.md
T
Tianyi Cui 7c400e9c02 docs: unify ADR/RFC trees into one lifecycle-organized RFC tree
Collapse docs/adr/ and docs/rfc/ into a single docs/rfc/ with proposed/,
implemented/, and rejected/ subfolders. Every file is renamed to
yyyy-mm-dd-topic-title.md, where the date is when the topic was first
proposed (from git history). ADRs and RFCs that covered exactly the same
topic are merged (property-based testing, session persistence); the
umbrella RFC 005 stays split across its three implemented decisions, and
RFC 006's deferred part-3 (API extractor reports) splits into its own
proposed RFC. All cross-references become machine-checkable relative
links instead of bare "ADR NNNN" / "RFC NNN" prose.

Add a verify-md-links doc-sync gate (scripts/verify-md-links.ts) that
checks every relative Markdown cross-link resolves, wired into doc-sync
alongside verify-md-wrap. This makes the reorganization self-verifying:
the same change that rewrote ~forty inter-doc links adds the check that
proves none dangle. Document the cross-link convention in a new
docs/AGENTS.md and record the gate as an implemented RFC.

doc-sync, typecheck, lint, and the full test suite (667) all pass.
2026-06-18 02:18:24 +08:00

2.9 KiB

RFC: Two LLM adapters as a design-verification twin

Status: implemented (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 (the content-block vocabulary). 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-rolled fetch + SSE parsing against the DeepSeek API.
  • dsh-llm-pi-ai — the same endpoint through the @earendil-works/pi-ai library (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 architectural conformance cover the contract mechanically), retiring the twin to a single adapter + the conformance kit would be a new RFC superseding this one.