docs: update backend references to worker-shell and worker-javascript

Rename WorkerBackend to WorkerShellBackend and IsolateJavaScriptBackend
to WorkerJavaScriptBackend throughout the design docs, along with the
backends/worker-shell and backends/worker-javascript import subpaths and
the worker-shell and worker-javascript selector ids.

Author: aron-cf

docs/05_runtime_interface.md

@@ -62,13 +62,13 @@ interface WorkspaceRuntimeResult {
 }
 ```
 
-Command backends leave `value` unset. `isolate-javascript` uses `value` for the module's structured return value and reports a zero-entry completed sync. A command can complete while its post-command pull fails; in that case `sync.status` is `"pending"`, and a configured `SyncRetryScheduler` can durably retry the pull without rerunning the command.
+Command backends leave `value` unset. `worker-javascript` uses `value` for the module's structured return value and reports a zero-entry completed sync. A command can complete while its post-command pull fails; in that case `sync.status` is `"pending"`, and a configured `SyncRetryScheduler` can durably retry the pull without rerunning the command.
 
 ## Backend routing
 
 ```ts
 await workspace.runtime.exec("grep -R TODO .", {
-  backend: "isolate-shell",
+  backend: "worker-shell",
 });
 
 await workspace.runtime.exec("npm test", {
@@ -80,7 +80,7 @@ await workspace.runtime.exec(
     import fs from "node:fs/promises";
     export default async () => fs.readFile("/workspace/package.json", "utf8");
   `,
-  { backend: "isolate-javascript" },
+  { backend: "worker-javascript" },
 );
 ```
 
@@ -94,16 +94,16 @@ Command backends continue to use the existing synchronization bracket:
 push → spawn → events/result → pull
 ```
 
-A backend with `sync: "none"`, such as `isolate-shell`, shares the host store and reports zero push/pull counts. A Container has its own VFS and synchronizes changes before and after command execution. Fully draining either `result()` or the event stream completes the post-command pull before the stream closes.
+A backend with `sync: "none"`, such as `worker-shell`, shares the host store and reports zero push/pull counts. A Container has its own VFS and synchronizes changes before and after command execution. Fully draining either `result()` or the event stream completes the post-command pull before the stream closes.
 
 Module backends use host capability calls against the authoritative Workspace and therefore require no push/pull round trip.
 
 ## Lifecycle differences
 
 `container-shell` provides computerd's retained process log, replay, signals, and disposal.
 
-`isolate-javascript` provides a Workspace-owned execution journal, retained result/events, host cancellation, and explicit disposal. Active Workers cannot be serialized across host restart; orphaned running records are reconciled to failed.
+`worker-javascript` provides a Workspace-owned execution journal, retained result/events, host cancellation, and explicit disposal. Active Workers cannot be serialized across host restart; orphaned running records are reconciled to failed.
 
-`isolate-shell` intentionally preserves one-call, buffered-result behavior in this release. It does not retain executions for later reattachment or disposal. `timeoutMs` and a concurrent `killExec()` for a caller-supplied execution ID cooperatively abort just-bash at statement boundaries; by the time an ordinary `exec()` promise returns, the command has already settled. Use the Container or JavaScript isolate when detached execution and retained lifecycle are required.
+`worker-shell` intentionally preserves one-call, buffered-result behavior in this release. It does not retain executions for later reattachment or disposal. `timeoutMs` and a concurrent `killExec()` for a caller-supplied execution ID cooperatively abort just-bash at statement boundaries; by the time an ordinary `exec()` promise returns, the command has already settled. Use the Container or JavaScript isolate when detached execution and retained lifecycle are required.
 
 See [16. Execution runtime architecture](./16_code_execution.md) and [17. Isolate JavaScript](./17_isolate_javascript.md).

docs/09_tool_interface.md

@@ -55,7 +55,7 @@ When assigning the same instance to `Think.workspace`, construct it with `useThi
 const workspace = new Workspace({
   storage: ctx.storage,
   backends: [
-    new WorkerBackend({ id: "shell", /* ... */ }),
+    new WorkerShellBackend({ id: "shell", /* ... */ }),
     new CloudflareContainerBackend({ id: "container", /* ... */ }),
   ],
 });

docs/10_project_layout.md

@@ -199,7 +199,7 @@ Runnable examples live at the repo root, not inside any package:
 ```
 examples/
 ├── container/        # Reference container image for computerd
-├── worker/           # WorkerBackend example
+├── worker-shell/     # WorkerShellBackend example
 ├── code/             # workspace.runtime with Worker and Container shells
 └── think/            # @cloudflare/think integration
 ```
@@ -210,7 +210,7 @@ so each example can declare its own dependencies and scripts.
 ## Testing
 
 - **Unit tests live next to source.** Packages follow the `foo.ts` + `foo.test.ts` convention.
-- **Workerd integration tests** for WorkerBackend, Workspace RPC, and `workspace.runtime` live in `packages/computer/tests/` with dedicated Vitest and Wrangler configuration.
+- **Workerd integration tests** for WorkerShellBackend, Workspace RPC, and `workspace.runtime` live in `packages/computer/tests/` with dedicated Vitest and Wrangler configuration.
 - **Container and load harness tests** live in `packages/computer/test-harness/`:
   - `end-to-end.test.ts` — DO ↔ container round-trip
   - `shell.test.ts` — shell surface against a real backend

docs/12_worker_backend.md

@@ -2,7 +2,7 @@
 
 > [!NOTE]
 > This doc reflects shipped code in
-> `packages/computer/src/backends/worker/`. The example deployment
+> `packages/computer/src/backends/worker-shell/`. The example deployment
 > lives at `examples/worker/`.
 
 The worker backend is the second `WorkspaceBackend` shape the
@@ -17,7 +17,7 @@ Import via the sub-path so the bundled just-bash payload tree-shakes
 out of consumers that don't use it:
 
 ```ts
-import { WorkerBackend } from "@cloudflare/computer/backends/worker";
+import { WorkerShellBackend } from "@cloudflare/computer/backends/worker-shell";
 ```
 
 ## When to reach for it
@@ -32,7 +32,7 @@ isolate that boots instantly, scales out cheaply, and has no
 container lifecycle. The shell is the just-bash interpreter; the
 supported command set is broad (`cat`, `grep`, `awk`, `sed`, `jq`,
 `sort`) but not the full Linux userland. JavaScript modules run through the
-[`isolate-javascript` backend](./17_isolate_javascript.md), not through just-bash's
+[`worker-javascript` backend](./17_isolate_javascript.md), not through just-bash's
 Node-only language commands. Filesystem operations forward into the same
 SQLite store as the container backend, so the storage shape, mount
 rules, and read-only enforcement are unchanged.
@@ -55,7 +55,7 @@ Reach for the container backend when the agent runs `npm`, a real language runti
 agent code
   │  Workers RPC
   ▼
-host DO ─── Workspace ─── WorkerBackend
+host DO ─── Workspace ─── WorkerShellBackend
                               │
                               │  env.LOADER.get(loaderId, codeCallback)
                               │    .getEntrypoint("ShellWorker")
@@ -158,7 +158,7 @@ they already handle.
 
 ## Fetcher factory escape hatch
 
-`WorkerBackend` is source-agnostic. The common case takes
+`WorkerShellBackend` is source-agnostic. The common case takes
 `{ loader, workspace, ctx }` and builds the loader callback
 itself. For deployments that need a different Fetcher source — a
 Workers service binding, a Workers-for-Platforms dispatch
@@ -219,7 +219,7 @@ export class MyAgent extends DurableObject<Env> {
       storage: ctx.storage,
       sessionId: ctx.id.toString(),
       artifacts: { binding: env.ARTIFACTS },
-      backends: [new WorkerBackend(/* ... */)],
+      backends: [new WorkerShellBackend(/* ... */)],
     });
   }
 }
@@ -250,15 +250,15 @@ network-bound `git` subcommands do. See
   `/c/<name>/file/...` and `/c/<name>/exec` routes the container
   example also exposes).
 - No Dockerfile, no build script. The shell bundle ships with
-  `@cloudflare/computer/backends/worker` as `SHELL_MODULES`
+  `@cloudflare/computer/backends/worker-shell` as `SHELL_MODULES`
   (a record of module name → source covering the entry plus
   every code-split chunk); the backend hands the whole record
   to the Loader callback itself.
 
 The DO's backend wiring fits in three lines:
 
 ```ts
-new WorkerBackend({
+new WorkerShellBackend({
   loader: env.LOADER,
   workspace: { binding: "ContainerExample", id: ctx.id.toString() },
   ctx,

docs/13_git_interface.md

@@ -3,7 +3,7 @@
 > [!NOTE]
 > This doc describes shipped code in `packages/computer/src/git/`
 > and the `git` custom command in
-> `packages/computer/src/backends/worker/`. Everything below
+> `packages/computer/src/backends/worker-shell/`. Everything below
 > works today.
 
 `workspace.git` is a major typed surface on `Workspace`, alongside `fs`, `runtime`, Assets, and Artifacts. It runs every operation against the
@@ -1065,7 +1065,7 @@ commands receive the live host stub the shell already reached,
 so they share its lifetime without refetching.
 
 ```ts
-import { ShellWorker, defineGitCommand } from "@cloudflare/computer/backends/worker";
+import { ShellWorker, defineGitCommand } from "@cloudflare/computer/backends/worker-shell";
 import { type CustomCommand } from "just-bash";
 
 class MyShell extends ShellWorker {

docs/14_assets_interface.md

@@ -34,7 +34,7 @@ client when constructing the `Workspace`:
 ```ts
 const ws = new Workspace({
   storage: ctx.storage,
-  backends: [new WorkerBackend(/* ... */)],
+  backends: [new WorkerShellBackend(/* ... */)],
   assets: (ws) => createAssets({ ws, bucket: env.ASSETS, s3: { bucket: "agent-assets" }, env }),
 });
 ```

docs/15_artifacts_interface.md

@@ -3,7 +3,7 @@
 > [!NOTE]
 > This doc describes shipped code in
 > `packages/computer/src/artifacts/` and the `artifacts` custom
-> command in `packages/computer/src/backends/worker/`.
+> command in `packages/computer/src/backends/worker-shell/`.
 
 [Cloudflare Artifacts](https://developers.cloudflare.com/artifacts/)
 is versioned, Git-speaking repository storage. A Worker reaches it
@@ -250,7 +250,7 @@ export class MyAgent extends DurableObject<Env> {
       storage: ctx.storage,
       sessionId: ctx.id.toString(),
       artifacts: { binding: env.ARTIFACTS },
-      backends: [new WorkerBackend(/* ... */)],
+      backends: [new WorkerShellBackend(/* ... */)],
     });
   }
 }

docs/16_code_execution.md

@@ -16,8 +16,8 @@ The selected backend defines how it interprets `source`.
 | Backend | Source language | Intended use |
 | --- | --- | --- |
 | `container-shell` | shell command | Full Linux, native binaries, installed packages, processes |
-| `isolate-shell` | just-bash command | Fast text tools and Workspace Git without a Container |
-| `isolate-javascript` | ECMAScript module | Isolated structured JavaScript with trusted Workspace modules |
+| `worker-shell` | just-bash command | Fast text tools and Workspace Git without a Container |
+| `worker-javascript` | ECMAScript module | Isolated structured JavaScript with trusted Workspace modules |
 
 Applications may register additional command or module backends under their own IDs. Backend IDs are part of the execution contract: changing the backend may change the source language.
 
@@ -26,19 +26,19 @@ Applications may register additional command or module backends under their own
 ```ts
 const handle = await workspace.runtime.exec(source, {
   id: "build-1",
-  backend: "isolate-javascript",
+  backend: "worker-javascript",
 });
 
 handle.id;
 await handle.kill();
 
 const resumed = await workspace.runtime.getExec("build-1", {
-  backend: "isolate-javascript",
+  backend: "worker-javascript",
   resume: "full",
 });
 
 await workspace.runtime.disposeExec("build-1", {
-  backend: "isolate-javascript",
+  backend: "worker-javascript",
 });
 ```
 
@@ -59,9 +59,9 @@ interface WorkspaceRuntimeResult {
 
 Command backends leave `value` unset. Module backends use it for their structured return value.
 
-`container-shell` retains the existing computerd process lifecycle. `isolate-javascript` keeps an execution journal in the Workspace database and retains events/results until `disposeExec`. Active isolate cancellation is host-driven by disposing the child Worker. An execution left running across a Workspace host restart is reconciled to failed because a live Worker capability cannot be serialized into SQLite.
+`container-shell` retains the existing computerd process lifecycle. `worker-javascript` keeps an execution journal in the Workspace database and retains events/results until `disposeExec`. Active isolate cancellation is host-driven by disposing the child Worker. An execution left running across a Workspace host restart is reconciled to failed because a live Worker capability cannot be serialized into SQLite.
 
-`isolate-shell` intentionally retains its existing behavior in this release: it buffers a just-bash call to completion, does not retain cross-request events, and cannot reattach by ID. Callers that require supervised process behavior should use `container-shell`; callers that require a managed isolate should use `isolate-javascript`.
+`worker-shell` intentionally retains its existing behavior in this release: it buffers a just-bash call to completion, does not retain cross-request events, and cannot reattach by ID. Callers that require supervised process behavior should use `container-shell`; callers that require a managed isolate should use `worker-javascript`.
 
 ## Backend authority
 
@@ -70,14 +70,14 @@ There is no general `workspace.scope()` abstraction. Backend construction fixes
 For different authority levels, configure distinct backend instances:
 
 ```ts
-new IsolateJavaScriptBackend({
-  id: "isolate-javascript-readonly",
+new WorkerJavaScriptBackend({
+  id: "worker-javascript-readonly",
   loader: env.LOADER,
   access: "read",
 });
 
-new IsolateJavaScriptBackend({
-  id: "isolate-javascript",
+new WorkerJavaScriptBackend({
+  id: "worker-javascript",
   loader: env.LOADER,
   access: "read-write",
 });

docs/17_isolate_javascript.md

@@ -1,16 +1,16 @@
 # Isolate JavaScript runtime
 
-`IsolateJavaScriptBackend` runs an ECMAScript module in a fresh Cloudflare Dynamic Worker:
+`WorkerJavaScriptBackend` runs an ECMAScript module in a fresh Cloudflare Dynamic Worker:
 
 ```ts
 import { Workspace } from "@cloudflare/computer";
-import { IsolateJavaScriptBackend } from "@cloudflare/computer/backends/javascript";
+import { WorkerJavaScriptBackend } from "@cloudflare/computer/backends/worker-javascript";
 
 const workspace = new Workspace({
   storage: ctx.storage,
   waitUntil: ctx.waitUntil.bind(ctx),
   backends: [
-    new IsolateJavaScriptBackend({
+    new WorkerJavaScriptBackend({
       loader: env.LOADER,
       root: "/workspace",
       access: "read-write",
@@ -40,7 +40,7 @@ const handle = await workspace.runtime.exec(
     }
   `,
   {
-    backend: "isolate-javascript",
+    backend: "worker-javascript",
     input: { value: 21 },
     encoding: "utf8",
   },
@@ -70,7 +70,7 @@ await workspace.fs.writeFile(
 await workspace.runtime.exec(
   `import task from "./task.js"; export default task;`,
   {
-    backend: "isolate-javascript",
+    backend: "worker-javascript",
     cwd: "/workspace",
     input: { value: 42 },
   },
@@ -96,7 +96,7 @@ Host calls have a caller-visible deadline, controlled by `maxHostCallMs` and def
 Bare imports are installed at backend construction, not passed on individual executions:
 
 ```ts
-new IsolateJavaScriptBackend({
+new WorkerJavaScriptBackend({
   loader: env.LOADER,
   modules: {
     "tar-stream": TAR_STREAM_BUNDLE,
@@ -165,4 +165,4 @@ Console output is bounded but currently buffered in the Dynamic Worker and publi
 
 ## Trusted integrations
 
-A host can configure additional reserved capability modules through `IsolateJavaScriptBackend.trustedModules`; these modules are fixed when the backend is constructed and cannot be supplied or replaced by caller source.
+A host can configure additional reserved capability modules through `WorkerJavaScriptBackend.trustedModules`; these modules are fixed when the backend is constructed and cannot be supplied or replaced by caller source.

docs/18_runtime_migration.md

@@ -10,22 +10,22 @@ This change is a breaking preview-API migration. Public execution now uses one r
 | `workspace.shell.get(id, options)` | `workspace.runtime.getExec(id, options)` |
 | `workspace.shell.kill(id, options)` | `workspace.runtime.killExec(id, options)` |
 | `workspace.shell.dispose(id, options)` | `workspace.runtime.disposeExec(id, options)` |
-| `workspace.code` / script execution | `workspace.runtime.exec(source, { backend: "isolate-javascript", input })` |
+| `workspace.code` / script execution | `workspace.runtime.exec(source, { backend: "worker-javascript", input })` |
 
 `WorkspaceShell` still exists internally to implement command backends. It is not a public Workspace property.
 
 ## Default backend IDs
 
 - Cloudflare Container: `container-shell`
-- just-bash Dynamic Worker: `isolate-shell`
-- ECMAScript Dynamic Worker: `isolate-javascript`
+- just-bash Dynamic Worker: `worker-shell`
+- ECMAScript Dynamic Worker: `worker-javascript`
 
 The first configured backend is the default for `runtime.exec()`. Pass `backend` explicitly at security boundaries. Routing is not authorization: trusted gateways must choose from a host-owned allowlist rather than accepting an arbitrary model-supplied backend ID.
 
 ## Source semantics
 
-Command backends interpret the first argument as a shell command and reject structured `input`. `isolate-javascript` interprets it as an ECMAScript module and supports structured JSON-compatible input/results, durable relative modules, `node:fs/promises`, and host-owned trusted modules.
+Command backends interpret the first argument as a shell command and reject structured `input`. `worker-javascript` interprets it as an ECMAScript module and supports structured JSON-compatible input/results, durable relative modules, `node:fs/promises`, and host-owned trusted modules.
 
 ## Lifecycle differences
 
-Container command executions use the remote process journal and push/pull synchronization bracket. `isolate-shell` uses the documented limited one-call Worker lifecycle. `isolate-javascript` stores execution status and events in the Workspace database and supports replay, cancellation, disposal, and restart recovery. Completed filesystem and provider side effects are not rolled back when execution fails or is cancelled.
+Container command executions use the remote process journal and push/pull synchronization bracket. `worker-shell` uses the documented limited one-call Worker lifecycle. `worker-javascript` stores execution status and events in the Workspace database and supports replay, cancellation, disposal, and restart recovery. Completed filesystem and provider side effects are not rolled back when execution fails or is cancelled.