docs(i18n): align single-exe terminology

Add canonical Chinese bindings for build target, deploy root, peer
dependency, serving surface, wheel, wrapper, and VFS so future translations
have one source of truth. Apply the existing runtime, plugin, artifact, and
pipeline bindings throughout every Chinese counterpart touched by this PR.

Require the first Chinese use of peer dependency to retain the English term
so readers can map it back to the package-manager concept without
reintroducing mixed prose throughout the document.

Rewrite mixed-language prose where the English term is not an identifier,
while retaining package names, paths, flags, pkg, single-exe, and other
literal names exactly. Explain VFS on first use and keep technical constraints
readable without inventing compatibility terminology.

Describe single-executable worker support as implemented behavior, including
the filesystem-string entry contract and CommonJS worker artifact required by
the pkg loader, and remove the obsolete bundled-but-unsupported limitation.

Regenerate pairing fingerprints and the generated catalog reference so the
mechanical documentation gates validate the revised English and Chinese
pairs. This keeps the terminology table authoritative and prevents the two
languages from drifting as the runtime documentation evolves.
This commit is contained in:
Tianyi Cui
2026-07-13 21:03:25 +08:00
parent ebcfab1621
commit b49c37f83a
11 changed files with 69 additions and 62 deletions

View File

@@ -58,7 +58,7 @@ The exe's "must be explicitly configured" hard semantic is unchanged; the zero-c
## Disposition of worker-style plugins
`dsh-workflow-workerthread` and `dsh-code-runtime-worker` are supported inside the exe. Their built entries convert the sibling worker URL with `fileURLToPath()` and pass the resulting filesystem string to `Worker`, which is the form pkg's Worker hook resolves inside the VFS. The workflow engine keeps its data-URL bootstrap for unbuilt source execution; only its built sibling entry uses the filesystem string. The custom-config executable smoke loads both backends, invokes a real `run_code` call and a zero-agent `workflow` call, and requires each worker to return `42` from inside pkg's VFS.
`dsh-workflow-workerthread` and `dsh-code-runtime-worker` are supported inside the exe. Their built hosts convert the sibling `lib/worker.cjs` URL with `fileURLToPath()` and pass the resulting filesystem string to `Worker`, which is the form pkg's Worker hook resolves inside the VFS. The worker entries are CommonJS because that hook compiles VFS worker files as CommonJS. The workflow engine keeps its data-URL bootstrap for unbuilt source execution; only its built sibling entry uses the filesystem string. The custom-config executable smoke loads both backends, invokes a real `run_code` call and a zero-agent `workflow` call, and requires each worker to return `42` from inside pkg's VFS.
## Testing