Chinesezjc
9af1e5e9f0
The review found the 62 floor off by two (the marker's fixed prefix is 51 characters counting both square brackets, so marker(62) serializes to 63) and the constructor error over-claiming a bound the marker-as-envelope design does not deliver. Fixes: - MIN_LOG_BYTES is 64 (marker-only serialization fits with one byte of room); the JSDoc arithmetic counts the brackets; the rejection test pins 63; the forged-frame test uses 11 NULs (69 escaped) at 64. - The constructor error now states the marker-only guarantee, and the README Known Limitations (en + zh) records the real bound: a truncated run with admitted entries serializes its logs to maxLogBytes + marker + envelope. - The SIGXCPU-mask tests burn with time.process_time() instead of wall-clock perf_counter, so a contended CI runner cannot under-burn the budget. - The settlement note (en + zh) records the 64 floor and the marker envelope bound, including the zh pre-encode section that the earlier pass missed. - The README constructor-rejection list names the maxLogBytes floor. Pairings re-recorded; corpus-wide verify-translation-pairing passes 1004.
description, kind
| description | kind |
|---|---|
| Package map for the code-execution capability family: what program execution does for you, and which package owns each part. | package-group |
code-runtime/ — code-execution capability family
English | 中文
Summary
The code-runtime/ group provides program execution: a model writes one program that calls host-provided functions as ordinary async calls, and a runtime executes it in isolation and returns only what the program printed and returned. One package defines the shared capability (ctx.codeRuntime), a second executes TypeScript programs in a fresh Node worker thread, and a third owns the wire protocol between a Node host and a CPython subprocess for the Python backend. Every run is independent — no state carries from one program to the next — and failures come back as part of the result, so the caller can see why a program failed and feed that back to the model.
Table of Contents
Packages
These three packages together provide program execution; each README describes what its part does.
| Package | Role | ctx key |
|---|---|---|
code-runtime/ |
Defines what a code runtime does: run one program against host-provided bindings and report what it printed and returned | ctx.codeRuntime |
code-runtime-worker-thread/ |
Executes TypeScript programs, each in a fresh Node worker thread | registers ctx.codeRuntime |
code-runtime-python/ |
Owns the fd-3 wire protocol between a Node host and a CPython subprocess, the Python backend's protocol layer | — |
Related documentation
Start with the subsystem reference for the service contract, then the PTC mode design that consumes this capability and the capability-seam model it follows.
- Code runtime subsystem reference — request/result vocabulary, bindings, and the
ctx.codeRuntimecordis surface. - PTC mode Agent Note — how the tool registry presents
run_codeto the model. - Capability seams — the Service Definition / Service Provider / Consumer split this family follows.
Dev Note
Working context for maintainers — click to expand
None.