Chinesezjc
2a9a917853
`sendReply` already refuses to write after the run settled, but only after `snapshotJsonValue` walked and copied the resolution. Binding resolution carries no seam-level byte cap, so a binding resolving a wide value after `maxWallMs`, an abort, or dispose settled the run spent host heap building a frame that was then discarded. The check moves ahead of the snapshot. Also in this change: - `readProcessStart` moved after `messageOf`. Inserting it between `messageOf`'s JSDoc and its body left that function undocumented and the orphaned block reading as a second doc for the reader; `verify-export-jsdoc` does not catch it because `messageOf` is not exported. - The README pair adds the disposed-runtime rejection to `run()`'s public contract, which `src/index.ts` has enforced all along. - Known Limitations records three deferred constraints that until now existed only in review discussion: the combined log-and-value peak the load gate does not model, the host-side per-member expansion of a wide binding reply (owned by `packages/core/session`, and shared with the worker-thread backend), and the absence of fd-3 backpressure for concurrent replies. - The Agent Note's same-group section records the teardown identity guard and its two rulings, including why an ABSENT start-time reading proceeds rather than withholding the signal, and that reading it as a mismatch is what turned the three same-group heartbeat cases red on Linux.
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.