docs: refresh architecture and package wording

Author: aallam

docs/architecture/README.md

@@ -1,6 +1,6 @@
 # Execbox Architecture Overview
 
-Execbox is the code-execution part of the `execbox` workspace. It turns host tool catalogs into callable guest namespaces, lets those namespaces wrap MCP tools, and pairs with executor packages that decide where and how guest JavaScript runs.
+Execbox is the code-execution part of the `execbox` workspace. It turns host tool catalogs into callable guest namespaces, lets those namespaces wrap MCP tools, and uses executor backends that decide where and how guest JavaScript runs.
 
 This doc set is for two audiences:
 

docs/architecture/execbox-executors.md

@@ -1,6 +1,6 @@
 # Execbox Executors
 
-This page explains how the current executors and QuickJS host modes differ and what trade-offs they make.
+This page explains how the available executors and QuickJS host modes differ and what trade-offs they make.
 
 ## Executor Comparison
 
@@ -60,7 +60,7 @@ That design gives QuickJS two useful properties:
 
 That means:
 
-- it does not depend on `execbox-protocol`
+- it does not use `@execbox/core/protocol`
 - it avoids the extra message loop used by worker-backed execution
 - its runtime-specific bridge logic still lives in the executor package itself
 - it aligns to the same runner-level shape used by QuickJS and transport-backed execution
@@ -69,7 +69,7 @@ The package keeps its native bridge where it belongs while still sharing the sam
 
 ## Worker-Hosted QuickJS
 
-`QuickJsExecutor` with `host: "worker"` uses a worker thread for lifecycle isolation, but it does not invent a second scripting model. It loads the same QuickJS session runner used by the inline QuickJS executor, reuses the shared QuickJS protocol endpoint inside the worker, and uses the shared `execbox-protocol` host session on the parent side. By default it keeps a worker shell warm between executions; `mode: "ephemeral"` switches to a fresh worker per execution.
+`QuickJsExecutor` with `host: "worker"` uses a worker thread for lifecycle isolation, but it does not invent a second scripting model. It loads the same QuickJS session runner used by the inline QuickJS executor, reuses the shared QuickJS protocol endpoint inside the worker, and uses the shared `@execbox/core/protocol` host session on the parent side. By default it keeps a worker shell warm between executions; `mode: "ephemeral"` switches to a fresh worker per execution.
 
 ```mermaid
 sequenceDiagram
@@ -90,7 +90,7 @@ sequenceDiagram
 
 ## Process-Hosted QuickJS
 
-`QuickJsExecutor` with `host: "process"` uses the same message-driven model as the worker host, but runs it behind a child-process boundary. It loads the same QuickJS session runner used by the inline QuickJS executor, reuses the same QuickJS protocol endpoint inside the child, and uses the shared `execbox-protocol` host session on the parent side. By default it keeps a child-process shell warm between executions; `mode: "ephemeral"` switches to a fresh child process per execution.
+`QuickJsExecutor` with `host: "process"` uses the same message-driven model as the worker host, but runs it behind a child-process boundary. It loads the same QuickJS session runner used by the inline QuickJS executor, reuses the same QuickJS protocol endpoint inside the child, and uses the shared `@execbox/core/protocol` host session on the parent side. By default it keeps a child-process shell warm between executions; `mode: "ephemeral"` switches to a fresh child process per execution.
 
 ```mermaid
 sequenceDiagram

docs/architecture/execbox-protocol-reference.md

@@ -274,7 +274,7 @@ Example execution with one tool call:
 
 ## Scope Of This Reference
 
-This reference describes the current message contract and host-session semantics used inside the execbox package family. It does not specify:
+This reference describes the message contract and host-session semantics used inside the execbox package family. It does not specify:
 
 - a built-in network transport such as HTTP or WebSocket
 - multi-execution multiplexing over one shared long-lived channel

docs/architecture/execbox-runner-specification.md

@@ -22,7 +22,7 @@ Use it when you want to implement a non-TypeScript runner, such as a Go remote r
 
 ## Status And Scope
 
-This is the normative runner specification for the current execbox runner contract.
+This is the normative runner specification for the execbox runner contract.
 
 It defines:
 

docs/architecture/index.md

@@ -1,6 +1,6 @@
 # Execbox Architecture Overview
 
-Execbox is the code-execution part of the `execbox` workspace. It turns host tool catalogs into callable guest namespaces, lets those namespaces wrap MCP tools, and pairs with executor packages that decide where and how guest JavaScript runs.
+Execbox is the code-execution part of the `execbox` workspace. It turns host tool catalogs into callable guest namespaces, lets those namespaces wrap MCP tools, and uses executor backends that decide where and how guest JavaScript runs.
 
 This doc set is for two audiences:
 

docs/index.md

@@ -14,9 +14,6 @@ hero:
     - theme: alt
       text: Explore Examples
       link: /examples
-    - theme: alt
-      text: Read the Architecture
-      link: /architecture/
 
 features:
   - title: Code-first tool use

packages/core/README.md

@@ -16,7 +16,7 @@ Docs: https://execbox.aallam.com
 
 ## Pair It With an Executor
 
-`@execbox/core` does not execute code on its own. Pair it with one of the executor packages:
+`@execbox/core` does not execute code on its own. Pair it with an executor backend:
 
 | Package                                                                      | Best for                                                                    |
 | ---------------------------------------------------------------------------- | --------------------------------------------------------------------------- |

packages/remote/README.md

@@ -7,7 +7,7 @@ Transport-backed remote executor for `@execbox/core`.
 
 Docs: https://execbox.aallam.com
 
-## Choose `execbox-remote` When
+## Choose `@execbox/remote` When
 
 - you want execbox execution to live outside the application process
 - you already own the transport and runtime deployment shape