Coder/deepseek-harness
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

docs(tools): count the union member as an edit, and re-scope the runtime guards

Browse Source 
The 'adding a language is two table entries plus its renderer' checklist
predates the `CodeSdkLanguage` union and now contradicts the mechanism
sentence beside it: following it literally leaves the union untouched, which
is exactly the excess-property error that sentence promises. It is three
parallel edits, in the note's Decision and Consequences and in the
`SDK_RENDERERS` JSDoc.

Two guard descriptions still claimed work the compiler took over. The
Decision's 'the drift this guards against' now names the `satisfies` pins and
leaves the guards their reachable case, a mounted runtime reporting a language
neither table knows; `resolveFlavor`'s JSDoc drops 'keeps the table coupled to
SDK_RENDERERS' for the same reason. The Consequences said a half-added
language 'cannot arise' for the runtime guards — it can, one PR later at the
consumer's integration point, and never on this base; the claim is now about
timing rather than impossibility.
This commit is contained in:
Chinesezjc
2026-08-05 23:44:26 +08:00
parent 9b3a0982c8
commit 05426906b0
5 changed files with 15 additions and 13 deletions
Download Patch File Download Diff File Expand all files Collapse all files

6
packages/core/tools/src/code-mode.ts
View File

@@ -135,8 +135,10 @@ const RUN_CODE_DESCRIPTION_PARAM_DESCRIPTION
* runtime is mounted — the static schema harvest (doc catalog), which never
* reaches a model — so that path degrades to {@link TYPESCRIPT_FLAVOR}. A
* mounted runtime whose language has no flavor entry fails loud, exactly as
* `requireCodeRuntime` rejects it at assembly: this keeps the table coupled to
* `SDK_RENDERERS` and never emits a wrong-language schema for a real runtime.
* `requireCodeRuntime` rejects it at assembly. Keeping this table in step with
* `SDK_RENDERERS` is the compiler's job ({@link CodeSdkLanguage}); what this
* guard owns is the runtime-supplied language neither table knows, which never
* yields a wrong-language schema for a real runtime.
*/
function resolveFlavor(peekRuntime: () => CodeRuntime | undefined): RunCodeFlavor {
const runtime = peekRuntime()

10
packages/core/tools/src/index.ts
View File

@@ -32,11 +32,11 @@ import { renderToolsSdkPy } from './py-types.ts'
* `ctx.codeRuntime.language` in this table when assembling the `tools:sdk`
* section under a non-native mode; a runtime whose language is not a key
* fails the assembly loudly (same idiom as `toolOrder` violations). Adding a
* new backend language is two table entries — an entry here and a
* `RUN_CODE_FLAVORS` entry in `code-mode.ts` for its `run_code` schema strings
* — plus the renderer function this table points at. The `satisfies` clause
* pins this table's key set to {@link CodeSdkLanguage}, the same union the
* flavor table is checked against, so adding one entry without the other is a
* new backend language is three parallel edits — a {@link CodeSdkLanguage}
* member, an entry here, and a `RUN_CODE_FLAVORS` entry in `code-mode.ts` for
* its `run_code` schema strings — plus the renderer function this table points
* at. The `satisfies` clause pins this table's key set to that union, which
* the flavor table is checked against too, so any of the three left out is a
* typecheck failure.
*/
const SDK_RENDERERS: Record<string, (schemas: ToolSdkSchema[]) => string> = {