Hare/yoi
1
1
Fork 0
Code Actions Packages Releases Activity

docs: consolidate design documentation and standardize crate English

Browse Source
This commit is contained in:
Hare
2026-10-12 14:58:00 +09:00
parent a633a53274
commit 4efb0ace1f
404 changed files with 4556 additions and 11654 deletions
Download Patch File Download Diff File Expand all files Collapse all files
crates/worker-runtime/README.md
+6 -41
View File
@@ -1,45 +1,10 @@
# worker-runtime
`worker-runtime` owns the Runtime authority surface for Worker management. A Runtime process bundles Worker lifecycle management, the HTTP/WebSocket control API, and the Worker execution backend.
Manages Worker creation, stopping, and Restore, execution connections within the Runtime, and Workdir materialization. The Backend owns Workspace records and grants; the Worker controller owns model execution and input acceptance. Optional features provide HTTP/WebSocket and filesystem persistence.
## Run the local Runtime server
## Reference index
From the repository root:
```bash
cargo run -p worker-runtime \
--bin yoi-runtime \
-- --bind 127.0.0.1:38800
```
By default the server listens on:
```text
127.0.0.1:38800
```
To bind another address explicitly:
```bash
cargo run -p worker-runtime \
--bin yoi-runtime \
-- --bind 0.0.0.0:38800
```
The REST server is intended for a trusted Backend/proxy, not direct browser access.
Workspace requests authenticate the actual HTTP request with the Workspace's current
signing identity. The Runtime verifies signatures against its explicitly enrolled
Workspace public key and binds the Runtime audience, Workspace/Worker scope,
operation, method, path/query, body digest, expiry, and single-use token ID. A
connection test is an ordinary signed `/v1/ping`; no prior handshake or saved
verification evidence is required or consulted.
Keep `trust-workspace add`, `replace`, and `revoke` as explicit operator actions.
A self-reported public key cannot grant trust. Trust record IDs are administrative
only and must not be copied into Backend registration or request claims. Replay
protection uses Workspace plus the trusted key fingerprint, so re-enrolling the
same key or rotating away and back cannot reset consumed requests. Reaccepting a
key does permit fresh, unconsumed requests signed by that key until their short
expiry; it does not create a separate sender-controlled enrollment namespace.
For authenticated remote Runtime setup, see [`../../docs/development/server-runtime-auth.md`](../../docs/development/server-runtime-auth.md).
- [`Runtime`](crate::Runtime): lifecycle operation acceptance, Workspace boundaries, and execution connections.
- [`execution`] — execution backends and operation-specific results.
- [`working_directory`] — repository materialization, session resources, and safe deletion.
- [`workspace_issuer`] — Workspace signature verification and replay prevention.