Tianyi Cui
e20ce35ffb
Two findings from the GitHub review bot on the ready PR: The tsdown two-entry build emitted the shared bootstrap module as a lib/bootstrap-*.js chunk imported by both bundles, which the package.json files whitelist (deliberately exact) omitted — a packed install had dangling imports. The package now runs two single-entry builds, so each bundle inlines its own bootstrap copy and every shipped file is self-contained. prepareValue admitted any cloneable value whose BOUNDED inspect rendering fit maxValueBytes, so a huge container with a compact rendering (a 50k-element array renders as '... N more items') crossed the port raw, bypassing the cap on both sides. The cap now measures the value's real cross-boundary size — exact bytes for strings, the structured-clone wire size (v8.serialize) for everything else — and oversized containers cross as their bounded rendering instead.
code-runtime/ — code-execution capability family
The code-execution capability seam (see capability seams): an abstract runtime interface for executing one model-written program against host-provided async bindings, capturing what it printed and returned. The consumer is the tool registry's Code Mode, specified alongside the seam in the Code Mode RFC. Product packages.
| Package | Role | ctx key |
|---|---|---|
code-runtime/ |
Abstract code-execution seam (interface + vocabulary) | ctx.codeRuntime |
code-runtime-worker/ |
Worker-thread backend: fresh worker per run, TypeScript via host-side type-strip, port-bridged bindings, budget/heap containment | registers ctx.codeRuntime |
The interface lives at code-runtime/code-runtime/; the shipped backend at code-runtime/code-runtime-worker/. Backends differ by execution substrate (worker thread, process, container) and by source language — both readonly descriptors on the service — and register ctx.codeRuntime without touching the interface or its consumer; that split is what makes a hardened backend a drop-in later.