You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Simplify pre-1.0 runtime boundaries. `@execbox/core/runtime` replaces the unsupported `@execbox/core/_internal` subpath and now owns executor-author helpers such as runtime option resolution, manifest dispatch, code normalization, timeout helpers, log formatting, and error normalization. The main `@execbox/core` entrypoint is now focused on app-facing provider, executor, result, error, and typegen APIs.
9
+
10
+
Move the QuickJS remote runner endpoint to `@execbox/quickjs/remote-endpoint` and remove the hidden `@execbox/quickjs` dependency from `@execbox/remote`. Remote transports now expose only `RemoteExecutor`, `RemoteRunnerPort`, and transport contracts from `@execbox/remote`.
|`@execbox/core`|App-facing core types, provider resolution, MCP adapters, plus runtime and protocol subpaths |
46
+
|`@execbox/quickjs`| Default QuickJS executor package with inline, worker-hosted, and process-hosted modes plus a reusable runner |
47
+
|`@execbox/remote`| Transport-backed executor that runs against an app-defined runner boundary|
48
+
|`@execbox/isolated-vm`| Alternate executor backend using a fresh `isolated-vm` context and a reusable isolated-vm runner |
49
49
50
50
## End-to-End Execution Model
51
51
@@ -100,4 +100,4 @@ Key implications:
100
100
101
101
## Architecture In One Paragraph
102
102
103
-
`@execbox/core` owns the stable execution contract, provider resolution, shared runner semantics, MCP adapters, and the `@execbox/core/protocol` transport surface. `@execbox/quickjs` and `@execbox/isolated-vm` each expose a runtime-specific reusable runner. Hosted `@execbox/quickjs` modes and `@execbox/remote` sit on top of `@execbox/core/protocol`, which owns the transport boundary: message shapes, shared host sessions, and reusable resource pools for transport-backed execution.
103
+
`@execbox/core` owns the app-facing execution contract, provider resolution, MCP adapters, and the `@execbox/core/protocol` transport surface. Runtime implementers use `@execbox/core/runtime` for shared dispatch, manifest, timeout, log, and normalization helpers. `@execbox/quickjs` and `@execbox/isolated-vm` each expose a runtime-specific reusable runner. Hosted `@execbox/quickjs` modes and `@execbox/remote` sit on top of `@execbox/core/protocol`, which owns the transport boundary: message shapes, shared host sessions, and reusable resource pools for transport-backed execution.
Copy file name to clipboardExpand all lines: docs/architecture/execbox-core.md
+14-12Lines changed: 14 additions & 12 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -17,8 +17,8 @@ This page covers the parts of execbox that stay stable regardless of which execu
17
17
The core package exposes three main responsibilities:
18
18
19
19
- Resolve host-authored tools into a deterministic guest namespace
20
-
-Normalize guest code into an executable async shape
21
-
-Define the stable execution contract and shared runner semantics used by all executors
20
+
-Define the stable app-facing execution contract
21
+
-Provide runtime implementers with shared runner semantics through `@execbox/core/runtime`
22
22
23
23
The main public concepts are:
24
24
@@ -66,7 +66,7 @@ The resolved provider also carries two maps:
66
66
67
67
## Guest Code Normalization
68
68
69
-
Executors do not evaluate arbitrary snippets directly. `normalizeCode()`first turns model- or user-produced text into a consistent async function body.
69
+
Executors do not evaluate arbitrary snippets directly. Runtime implementers import `normalizeCode()`from `@execbox/core/runtime` to turn model- or user-produced text into a consistent async function body.
70
70
71
71
That normalization handles:
72
72
@@ -79,27 +79,28 @@ The practical effect is that all executors can treat guest code as “an async f
79
79
80
80
## Shared Runner Semantics
81
81
82
-
The core package owns the small runner-level contract that sits between resolved providers and runtime-specific runners.
82
+
The `@execbox/core/runtime` entrypoint owns the small runner-level helper surface that sits between resolved providers and runtime-specific runners.
83
83
84
84
That contract is intentionally transport-neutral:
85
85
86
86
-`extractProviderManifests()` converts resolved providers into transport-safe manifests
87
87
-`createToolCallDispatcher()` turns a runner-emitted tool call back into a trusted host invocation
88
-
-`ExecutorRuntimeOptions` carries timeout, memory, and log limits in a runtime-agnostic form
88
+
-`resolveExecutorRuntimeOptions()` applies shared timeout, memory, and log defaults
89
+
-`ExecutorRuntimeOptions` carries the runtime-agnostic limit shape used by public executor options
Swap in `@execbox/remote` or `@execbox/isolated-vm` when you need a different runtime boundary.
34
34
35
+
## Runtime Implementer Surface
36
+
37
+
Application code should usually import from `@execbox/core`, `@execbox/core/mcp`, or `@execbox/core/protocol`.
38
+
Executor and runner packages should import shared runtime helpers from `@execbox/core/runtime` instead. That subpath contains the manifest dispatcher, runtime option defaults, timeout helpers, log formatting, code normalization, and error normalization used to keep runtime implementations aligned.
0 commit comments