mirror of
https://github.com/deepseek-ai/deepseek-harness
synced 2026-08-15 21:04:50 +00:00
New doc-sync gate verify-export-jsdoc walks every module-level exported name under packages/*/*/src and requires description prose everywhere, plus @param per parameter and @returns on non-void annotated returns for function-like exports, public class methods, properties, and accessors. The parsing + check helpers move out of gen-cordis-catalog.ts into a shared scripts/jsdoc.ts so 'documented' means one thing on both gated surfaces. Deliberate exemptions (documented in the RFC): heritage-declared class members (the seam declaration is the doc's one home — the one checker query in an otherwise pure-AST walk), cordis plugin-protocol slots (name/inject/reusable/Config/apply, top-level and static), constructors, overload implementations, declare-module augmentation bodies, and re-export statements (checked at the defining module). The 203 under-documented exports the gate found at adoption are filled in this change, so the gate lands green; generated catalogs/graphs are regenerated for the shifted line pointers. RFC: docs/rfc/implemented/process/2026-07-06-export-surface-jsdoc-gate.md
dsh-system-prompt
System prompt assembly registry. Plugins contribute ordered text sections, tool-schema providers, and named prompt variables; the agent loop calls assemble(context) once per step, and renderPrompt(assembly) is the full system prompt the model sees. The plugin registers the harness-owned openers itself — the static harness:identity section and the deployment's deployment:persona section — so they exist for every agent regardless of which loop plugin drives it.
Config
| Key | Default | Meaning |
|---|---|---|
persona |
'' |
The deployment persona: the ONE deployment-authored prompt fragment, rendered as the order-0 deployment:persona section and shared by every agent in the context (subagents included). A template — complete {{…}} groups are interpreted strictly against the registered variables (the shipped loop registers {{model}}/{{cwd}}), with no escape syntax for literal braces yet. Empty ⇒ the section is dropped at render. |
Service: SystemPrompt (ctx key: systemPrompt)
Public API
ctx.systemPrompt.section(section: PromptSection): () => voidContribute a section. Duplicate names throw. Disposed with the calling fiber.ctx.systemPrompt.tools(provider: () => ToolSchema[]): () => voidContribute tool schemas (evaluated at each assembly). Disposed with the calling fiber.ctx.systemPrompt.variable(name: string, provider: (context) => string | undefined): () => voidContribute a prompt variable, referenced from section text as{{name}}. Duplicate or unreferenceable names throw;undefinedmeans "no value for this assembly". Disposed with the calling fiber.ctx.systemPrompt.assemble(context?: AssembleContext): Promise<PromptAssembly>Assemble the prompt for one caller. Runs through thesystem-prompt/assemblewaterfall.
Events
| Event | Mode | Purpose |
|---|---|---|
system-prompt/assemble |
waterfall | Mutate/extend the assembly (with the caller's context) before it reaches the model |
system-prompt/change |
emit | A section, tool provider, or variable was registered or unregistered |
Key types
AssembleContext— what oneassemble()call is FOR. Declared empty here and merge-extensible;dsh-agentdeclaresagent?: Agent, so providers project per-agent facts. Providers must tolerate absent fields (a bareassemble()carries an empty context).PromptSection—{ name, order, text: string | ((context) => string) }. Sections are concatenated in ascendingorder. Order bands:-100is the harness identity,0the deployment persona (both registered by this plugin), tool guidance uses100–199; other negative orders also render before the persona.PromptAssembly—{ sections: AssembledSection[], tools: ToolSchema[], variables: Record<string, string | undefined> }. Section texts arrive resolved but not yet interpolated;variablesholds every registered variable resolved against the context. Tool schemas are part of the assembly by design: "what the model is told it can do" is one coherent thing, even though adapters transmit schemas as a separate wire field.renderPrompt(assembly)— interpolates{{variable}}references in each section, drops empty sections, joins with blank lines. STRICT: an unknown reference (Object.hasOwnlookup — prototype names like{{constructor}}are unknown), a registered-but-valueless reference, a malformed complete{{…}}group, or a{{that opens no complete group while a}}still follows ({{{model}}}) throws — fail loud beats shipping a malformed prompt. A lone{{with no}}anywhere after it passes through verbatim; substituted values are never re-scanned.
Merge-extensible: plugins can declare extra fields on PromptAssembly and AssembleContext via declaration merging.
Extension points
- Section providers: tool packages own their cross-call guidance (
tool:bash,tool:read, …); this plugin ownsharness:identityanddeployment:persona. - Variable providers: the agent loop registers
modelandcwd; any plugin can register the facts it owns (a futuredate, git state, …). - Tool schema providers:
ToolRegistryregisters itself as a tool provider automatically. - The
system-prompt/assemblewaterfall: mutate or replace the assembly per caller (dynamic tool filtering, extra variables).
What is NOT here
- Any deployment-authored prompt text outside config — the persona is this plugin's
personaconfig, and every other section comes from the plugin that owns the fact. (Theharness:identityline is deliberately a code literal: a harness fact, not a deployment choice; thesystem-prompt/assemblewaterfall is the escape valve for a deployment that must drop it.) - Prompt compaction (belongs on the
agent/pre-stepseam indsh-agent).
Design rationale: the prompt-variables RFC.