Finale: Five Engineering Views — What Should We Copy?

Play first, then the lecture. Below are the main mechanisms from the whole series as checkable cards — each tagged with the problem it solves and its prerequisite mechanisms. Pick what your project needs like ordering dishes; the right side builds your architecture list live: missing deps go red, scale traps warn whether you can afford them. Hit Play for a typical foot-gun-then-fix walkthrough.

The series dissects DSH, but every lesson compares with others. For the finale, put all five on one table. Three dimensions: source of truth (where the authoritative copy of conversation state lives), extension model (how third parties add capability), safety reliance (what keeps you from blowing up).

After the table, remember one thing: none of the five is right or wrong — only stance. Claude Code’s circuit-breaker numbers come from real bills; Grok’s static composition buys compile-time certainty; Codex writes distrust into the OS layer; OpenCode puts swappable models first. DSH’s peculiarity is ranking provability above “nice to use” — a runtime stance, and the root of its doc and test bulk.

The series covered ~30 mechanisms; most bind to DSH’s plugin framework. Five are pure ideas you can take and use:

1. Event-log source of truth. Conversation state lives in one append-only event sequence; the message array is always derived from it. One JSONL file plus a fold function is the minimal build — recovery and replay come free (details in Model-visible ⟺ logged).
2. Three input semantics. Messages users send while the agent works get three explicit fates — queue, interject, interrupt — as interface semantics. Without this layer, input timing is Schrödinger’s state.
3. Dual-path compaction. Active pressure probing and passive overflow recovery hang separately — different events, conditions, failure semantics (see Compaction Dual Paths).
4. Provenance auth. Every chunk entering context carries a source tag; high-privilege ops only trust trustworthy sources. Instructions hidden in tool results cannot impersonate the user.
5. Monotone Guard. Dangerous releases like retry and recovery always demand monotonically increasing evidence (generation numbers, counters) — never a plugin’s word alone.

What the five share: they are interface-semantics decisions, independent of language or framework. A weekend builds the rough cut; the rest is polish.

Conversely, three things DSH piled up with dedicated-team headcount — individuals and small teams will go sideways if they copy:

1. A 219-package plugin tree. Everything Is a Plugin means every capability splits into Service Definition, Provider, and Consumer roles, with README, tests, and doc pairing. DSH has 49 package groups and 268 READMEs. For the same need in your project, a plugins folder plus conventions is enough.
2. Bilingual three-file doc pairing. Each doc is English, Chinese, plus a .i18n.yaml recording both blob hashes — change one side without reconfirming the pair and CI goes red. Beautiful discipline; cost starts at 2× per doc change.
3. Per-file 100% coverage gate. Every source file needs 100% line coverage. DSH’s own proposed note (2026-06-11-mutation-testing) admits coverage only proves code ran. Without AI-scale test writing capacity, the gate just pushes “runs but never asserts” fake tests.

The finale doesn’t hype the hero. DSH is a developer preview; section 2 at the top of root AGENTS.md states the pre-release stance:

On MCP, only tools are bridged; Resources and Prompts are explicitly deferred — packages/mcp/mcp-client/README.md line 111: “Tools are the only bridged MCP capability — Resources and Prompts have no harness consumer and are deferred.” Product entry points are only Web UI and headless (apps/ has just cli and web) — no interactive TUI like Claude Code or Grok Build. These three aren’t black marks; they’re trade-offs: don’t pour the second floor before the foundation sets.

One last piece that’s easy to skip — and best explains DSH’s motive. Its four product modes are four preset config files; minimal mode’s core config is just these lines:

# The `minimal` agent preset: a fixed-prompt, two-tool coding-agent composition.
#
# The persona is the complete system prompt, so global identity, Web orientation,
# tool guidance, and later assembly listeners cannot add prompt text. Runtime
# context snapshots are suppressed for this preset, and the model composes only
# persistent `bash` and `str_replace_editor`. Context compaction is absent.

- id: persona
  name: '@deepseek-ai/dsh-persona'
  config:
    text: You are a helpful software engineer assistant.
    complete: true
    includeRuntimeContext: false

Read what this config does: the System Prompt is one sentence and marked complete — no plugin can add text; runtime context is suppressed; tools are only bash and str_replace_editor; no compaction. Every harness-side variable is wrung to the minimum. Root BENCHMARK.md recommends running this minimal variant via the Python SDK for benchmarks, with an independent workspace and session per task.

That explains one motive for DeepSeek building a harness: a model vendor needs a standardized, reproducible, compaction-free measuring instrument for its own models — and happened to ship a general runtime. Anthropic built Claude Code so the model serves the product; half of DeepSeek’s DSH is to measure the model itself. Different stance, different engineering view. Looking ahead, agentic RL training and model eval will only grow hungrier for replayable, provable harnesses — likely where DSH’s heavy-mechanism path pays off first.

The control group’s finales corroborate: Grok series Engineering retrospective & evidence boundary and Coding Agent design workbench answer the same questions from a Rust monolith angle — read both sides and the five engineering views line up.