kobako 0.26.0-aarch64-linux → 0.27.0-aarch64-linux

checksums.yaml

@@ -1,7 +1,7 @@
 ---
 SHA256:
-  metadata.gz: 0da2768b0825ee9390a7fa8b0ad607250c1e3414e2a087aa01e0a55c96d35c12
-  data.tar.gz: acfa3845f354764e12b8ede5d4c99a99da85338e7b6d4eb49c6ca57636e1e148
+  metadata.gz: 60336f7cdf1fe0abadc8ade4e40a549de94ecc3233c01b4b5f3f9dc584cd0f45
+  data.tar.gz: 7e9a80c3838fdc079548e2dfb448eebca2e7497c7195cc80dc36f5315592e9e0
 SHA512:
-  metadata.gz: 2f5e3091468ddc695bf76827b302964b10e310cac203f75d30d01f4548aaa2960148fef15256de3c9e512cbf3d73108fa62ad63b31653580801edef1c72b286c
-  data.tar.gz: f22415c61723f104638732c570e72ee468fb61c8d0ab4cca766a5822b6028ecaeb2e2ce6c85317390df7323c9d07f566d9f5beb5a0c7ad4931ffca416add0f92
+  metadata.gz: 3a94964cb83b51c3e528d4aab9555710032405e700ad8ffcceb3f9f629d79527bb4ad456d5e2ef84e4c5b7140d7841e8406e7d861086bbe1cbbffb1b4f027c32
+  data.tar.gz: 8c0b5786a0ebc742f7667afe7ed109e837d8260a02316bc36389bf54124321e7441ef2d020e1b0c63668c34a49a480cb95d3a68197a4da4da6eeeca92f8cc519

data/.release-please-manifest.json

@@ -1 +1 @@
-{".":"0.26.0","wasm/kobako-core":"0.16.0","wasm/kobako-mruby":"0.16.0","wasm/kobako-io":"0.16.0","wasm/kobako-json":"0.16.0","wasm/kobako-regexp":"0.16.0","wasm/kobako-baker":"0.16.0","crates/kobako-transport":"0.16.0","crates/kobako-codec":"0.16.0","crates/kobako-runtime":"0.16.0","crates/kobako-wasmtime":"0.16.0","crates/kobako":"0.16.0"}
+{".":"0.27.0","wasm/kobako-core":"0.17.0","wasm/kobako-mruby":"0.17.0","wasm/kobako-io":"0.17.0","wasm/kobako-json":"0.17.0","wasm/kobako-regexp":"0.17.0","wasm/kobako-baker":"0.17.0","crates/kobako-transport":"0.17.0","crates/kobako-codec":"0.17.0","crates/kobako-runtime":"0.17.0","crates/kobako-wasmtime":"0.17.0","crates/kobako":"0.17.0"}

data/CHANGELOG.md

@@ -1,5 +1,37 @@
 # Changelog
 
+## [0.27.0](https://github.com/elct9620/kobako/compare/v0.26.0...v0.27.0) (2026-09-20)
+
+
+### ⚠ BREAKING CHANGES
+
+* **guest:** a pattern's allocator is undefined from the moment the capability installs rather than from its first wrap, so allocating one is refused for the missing allocator throughout an invocation, where before the first statement could still reach an uninitialized carrier.
+* **mruby:** `kobako_mruby::dispatch` takes `Option<Proc>` where it took a `Value` that could be nil. A gem passes the block its method read off its own frame; `None` says there is none.
+* **json:** a JSON failure whose error class the guest replaced reaches the Host App as a guest exception rather than as a trap.
+* **json:** JSON.parse refuses a second positional argument. Options passed as a positional Hash, the shape MRI also refuses, must be written as keywords.
+* **mruby:** an object bearing a capability reference's class name without being one is refused as a value the wire cannot carry, where it previously crossed as a reference to whatever identifier it held.
+* **mruby:** an object whose class carries a list's or a map's name without being one is refused rather than read as that container, both as the invocation's own answer and as a dispatch argument.
+* **guest:** `Kobako::raise_transport_error`, `raise_service_error` and `reraise` are gone. A flow of its own builds `Kobako::transport_error` or `service_error` and hands the result back as `Err`, which beni raises at the guest call site.
+
+### Features
+
+* **gate:** hold a crate README's install snippet to its manifest ([31f6926](https://github.com/elct9620/kobako/commit/31f692602de6e1a2d9e5f84872164e83c4008e50))
+* **guest:** rebuild the guest crates on beni 0.17 ([b397701](https://github.com/elct9620/kobako/commit/b397701231c7d8718503d24f73b175676d0d1be3))
+* **guest:** rebuild the guest crates on beni 0.18 ([ae232eb](https://github.com/elct9620/kobako/commit/ae232ebbf708419ff0672172fbf8627363fb02da))
+
+
+### Bug Fixes
+
+* **json:** read a parse's options from the keywords it declares ([6f0c83c](https://github.com/elct9620/kobako/commit/6f0c83cc0b6ae0fe0f327ad0b514d46a6f3432c0))
+* **json:** report a replaced error class instead of ending the invocation ([5a75e42](https://github.com/elct9620/kobako/commit/5a75e42ba7990eb31d8487dd3979cca3c4a3d29b))
+* **mruby:** prove a container's layout by its tag, not its class name ([5ee8c59](https://github.com/elct9620/kobako/commit/5ee8c59db90cee27f356028ff466860afe89e06e))
+* **mruby:** read a reference's identity from the class the bridge registered ([0f24102](https://github.com/elct9620/kobako/commit/0f24102b75f771548cbc39256690e59d6df1f9e4))
+
+
+### Code Refactoring
+
+* **mruby:** carry a dispatch's block as the block it is ([01d8831](https://github.com/elct9620/kobako/commit/01d8831dff173e80c10d965af8615acb4de2498b))
+
 ## [0.26.0](https://github.com/elct9620/kobako/compare/v0.25.0...v0.26.0) (2026-09-15)
 
 

data/README.md

@@ -24,11 +24,14 @@ The host (`wasmtime`) runs a precompiled `kobako.wasm` guest containing mruby an
 
 ## Requirements
 
-- **Ruby ≥ 3.3.0**
-- **Rust / Cargo** at install time — the native extension compiles from source via `rb_sys`
-- **Linux** or **macOS** — Windows is not supported
+| What | Which versions | When you need it |
+|---|---|---|
+| Ruby | ≥ 3.3.0 | always |
+| Platform | Linux or macOS | always — Windows is not supported |
+| Rust / Cargo | current stable | only where no prebuilt gem matches your platform; otherwise the native extension installs ready-built |
+| WASI toolchain | vendored by the build | only when building the gem from a source checkout — see [Development](#development) |
 
-The precompiled `kobako.wasm` Guest Binary ships inside the gem, so end users do **not** need a WASI toolchain. (The toolchain is only required if you build the gem from a source checkout — see [Development](#development).)
+The precompiled `kobako.wasm` Guest Binary ships inside the gem, so end users do **not** need a WASI toolchain.
 
 ## Installation
 
@@ -63,9 +66,16 @@ The gem bundles its Guest Binary; a Rust host loads one explicitly — see [Fron
 
 ## Frontends & Guest Binaries
 
-Embedding kobako is two independent choices: the **host frontend** you build against, and the **Guest Binary** it runs. They compose freely — any frontend loads any Guest Binary, so a Ruby host can run a JSON-enabled guest and a Rust host can run the pure default.
+Embedding kobako is two independent choices: the **host frontend** you build against, and the **Guest Binary** it runs.
 
-How far down those choices go — and which ones a given starting point quietly makes for you — is laid out in [`docs/architecture.md`](docs/architecture.md).
+```text
+host frontend          Guest Binary
+  Ruby gem      ──┐  ┌── kobako.wasm (pure)
+  Rust SDK      ──┼──┼── kobako+regexp.wasm
+  your own      ──┘  └── kobako+json.wasm · your own
+```
+
+They compose freely — any frontend loads any Guest Binary, so a Ruby host can run a JSON-enabled guest and a Rust host can run the pure default. How far down those choices go — and which ones a given starting point quietly makes for you — is laid out in [`docs/architecture.md`](docs/architecture.md).
 
 ### Host frontends
 
@@ -149,6 +159,16 @@ Build the crate as a `cdylib` for `wasm32-wasip1`, then bake the canonical boot
 
 ## Usage
 
+Each section below stands on its own; this is the order they build in.
+
+| If you want to | Read |
+|---|---|
+| let guest code call into your host | [Services](#services), [Per-Invocation Bindings](#per-invocation-bindings), [Service Blocks](#service-blocks) |
+| see what a run produced or why it failed | [Output Capture](#output-capture), [Error Handling](#error-handling), [Invocation Lifecycle](#invocation-lifecycle) |
+| bound what a run may consume | [Resource Limits](#resource-limits), [Concurrency](#concurrency), [Pooling](#pooling) |
+| hand host objects across the boundary | [Handle Management](#handle-management) |
+| ship guest code with the Sandbox | [Snippets & Entrypoints](#snippets--entrypoints), [Extensions](#extensions) |
+
 ### Services
 
 `bind` any Ruby object as a Service at a constant-path name; the guest reaches it as a `MyService::KV` (or top-level `File`) proxy and invokes the public methods its own class defines through the Transport wire. See [`SV-006`](docs/spec/behavior/services.md) and [`SV-007`](docs/spec/behavior/services.md).
@@ -256,7 +276,14 @@ Beyond the four caps, `profile:` requests the Sandbox's isolation posture on the
 
 ### Concurrency
 
-A Sandbox keeps no state from any run, so concurrent Threads may invoke distinct Sandboxes or share a single one; each invocation owns its Handles, captures, and usage either way ([`RT-001`](docs/spec/behavior/runtime.md), [`RT-002`](docs/spec/behavior/runtime.md)). One Thread still runs one invocation at a time. Sharing a Sandbox adds a single obligation: an object bound once at setup is reached by every Thread and must itself be thread-safe, while an object supplied per invocation — `ctx.bind`, or an Extension `provider:` — carries no such requirement.
+A Sandbox keeps no state from any run, so concurrent Threads may invoke distinct Sandboxes or share a single one; each invocation owns its Handles, captures, and usage either way ([`RT-001`](docs/spec/behavior/runtime.md), [`RT-002`](docs/spec/behavior/runtime.md)). One Thread still runs one invocation at a time. Sharing a Sandbox adds a single obligation.
+
+| What you bind | Who reaches it | What it owes |
+|---|---|---|
+| Bound once at setup | every Thread sharing the Sandbox | it must itself be thread-safe |
+| Supplied per invocation — `ctx.bind`, or an Extension `provider:` | that invocation alone | nothing |
+
+#### Choosing a GVL mode
 
 By default an invocation holds Ruby's GVL for its whole span, so guest execution across Threads serializes. `gvl: :release` drops the GVL for the guest span and re-acquires it for each guest→host dispatch, running guest code in parallel across Threads ([`RT-024`](docs/spec/behavior/runtime.md), [`RT-026`](docs/spec/behavior/runtime.md)).
 
@@ -321,8 +348,6 @@ For workloads that must be isolated from each other (one Sandbox per tenant, per
 
 For hosts that serve many short invocations, `Kobako::Pool` keeps a bounded set of warm, identically set-up Sandboxes and hands each one to a single exclusive holder at a time ([`PL-003`](docs/spec/behavior/pool.md), [`PL-011`](docs/spec/behavior/pool.md)). Construction forwards every `Sandbox.new` keyword verbatim; the optional block is the per-Sandbox setup window and runs exactly once per constructed Sandbox.
 
-`Kobako::Pool` is experimental today and is best treated as a convenience for warm, pre-configured reuse rather than a throughput optimisation. The build bakes the shared boot state into the artifact ([`mruby.md`](docs/spec/behavior/mruby.md)) and every dynamic script still compiles and runs per invocation, so all a pool actually saves is the host-side `Sandbox.new` — now under 3 µs, an order of magnitude below the invocation that follows it. For the workload kobako is built for — many small, short-lived Sandboxes running dynamic scripts — that is not a gain worth the coupling. What a Pool buys is warm setup and exclusive checkout, not isolation: a Sandbox holds no state from any run, so Threads sharing one are equally safe (see [Concurrency](#concurrency)).
-
 ```ruby
 pool = Kobako::Pool.new(slots: 4) do |sandbox|
   sandbox.bind("KV::Lookup", ->(key) { redis.get(key) })
@@ -331,6 +356,8 @@ end
 pool.with { |sandbox| sandbox.eval(%(KV::Lookup.call("user_42"))).value }
 ```
 
+#### Options and lifetime
+
 | Option | Meaning | Default |
 |--------|---------|---------|
 | `slots:` | Upper bound on constructed Sandboxes | required |
@@ -338,6 +365,14 @@ pool.with { |sandbox| sandbox.eval(%(KV::Lookup.call("user_42"))).value }
 
 Sandboxes construct lazily on first demand. `#with` yields a Sandbox and returns the block's value; at block exit the Sandbox returns to the pool, except a block that raises `Kobako::TrapError` discards its Sandbox and the slot refills by a fresh construction on next demand. A checkout that waits past `checkout_timeout` raises `Kobako::PoolTimeoutError`. There is no teardown verb — a Pool releases everything with its own reachability.
 
+#### What a Pool buys
+
+| It gives you | It does not give you |
+|---|---|
+| warm, pre-configured Sandboxes and exclusive checkout | isolation — a Sandbox holds no state from any run, so Threads sharing one are equally safe (see [Concurrency](#concurrency)) |
+
+`Kobako::Pool` is experimental today and is best treated as a convenience for warm, pre-configured reuse rather than a throughput optimisation. The build bakes the shared boot state into the artifact ([`mruby.md`](docs/spec/behavior/mruby.md)) and every dynamic script still compiles and runs per invocation, so all a pool actually saves is the host-side `Sandbox.new` — now about 3 µs, an order of magnitude below the invocation that follows it. For the workload kobako is built for — many small, short-lived Sandboxes running dynamic scripts — that is not a gain worth the coupling.
+
 ### Service Blocks
 
 A Service method can accept a guest-supplied block via `&blk` and `yield` into it. The block body runs inside the Wasm guest; `break` / `next` / exceptions follow normal Ruby semantics, scoped to the single dispatch. See [`T-085`](docs/spec/behavior/transport-yield.md) and [`T-089`](docs/spec/behavior/transport-yield.md).
@@ -367,6 +402,8 @@ sandbox.eval('Factory::Make.call("Bob")').value        # => #<Greeter @name="Bob
 
 A `break` value from a guest block is the one exception: it unwinds back to the guest Service call rather than to host code, so a Handle in it stays a Handle — restoring would just re-wrap the same object into a new id on the return trip.
 
+#### One Handle per dispatch
+
 Each dispatch that hands back a non-wire-representable object allocates a *new* Handle — kobako never deduplicates by object identity ([`T-007`](docs/spec/behavior/transport-dispatch.md), [`T-009`](docs/spec/behavior/transport-dispatch.md)). This is most visible with fluent / builder APIs. An `ActiveRecord::Relation` chain `spawn`s a fresh relation at each step, so every hop is an independent dispatch that binds its own Handle:
 
 ```
@@ -417,6 +454,8 @@ A target no snippet defined raises `Kobako::UndefinedEntrypointError`, whose `#a
               return the Execution, then discard the instance
 ```
 
+#### Choosing a payload form
+
 `#preload` accepts two payload forms:
 
 | Form     | Signature                            | Snippet name source                   | Validation timing                                                          |
@@ -481,11 +520,22 @@ sandbox.bind("Cfg::Settings", ThemeReader.new)  # not: bind("Cfg::Settings", App
 sandbox.eval('Cfg::Settings.color').value  # => "#3366ff"  — every other method raises NoMethodError
 ```
 
+#### Gating an object's own surface
+
 When a purpose-built wrapper is more than you need, an object can gate its own surface in
 place: a private `respond_to_guest?(name)` answers, per method, whether the guest may call
 it. Returning `false` for every name makes the object opaque — a credential the guest
 forwards to another Service but never reads — while permitting a named subset exposes exactly those.
 
+```ruby
+class Credential
+  def initialize(token) = @token = token
+  def to_s = @token
+
+  private def respond_to_guest?(_name) = false  # forwardable, never readable
+end
+```
+
 Guest code can name any `MyService::KV` path, but a forged name only resolves to
 something you bound — the real authorization gate is this host-side allowlist. Give each
 trust context its own Sandbox, and see [`docs/security-model.md`](docs/security-model.md) for the rest
@@ -499,17 +549,25 @@ Order-of-magnitude figures on macOS arm64, Ruby 3.4.7, YJIT off. Absolute values
 | Phase                                                        | Cost                  |
 |--------------------------------------------------------------|-----------------------|
 | First `Sandbox.new` ever for a Guest Binary (Module JIT, then disk-cached) | ~500 ms once per machine |
-| First `Sandbox.new` in a fresh process (`.cwasm` cache warm) | ~1.3 ms one-time      |
+| First `Sandbox.new` in a fresh process (`.cwasm` cache warm) | ~3 ms one-time        |
 | Subsequent `Sandbox.new` (caches warm)                       | ~3 µs                 |
-| Warm `#eval` with one Service call on a reused Sandbox       | ~71 µs                |
-| Warm `#run(:Entrypoint, ...)` dispatch                       | ~81 µs                |
-| Service call amortized inside one invocation                 | ~5.7 µs               |
-| Snippet replay per invocation                                | ~7.5 µs each          |
+| Warm `#eval` with one Service call on a reused Sandbox       | ~70 µs                |
+| Warm `#run(:Entrypoint, ...)` dispatch                       | ~79 µs                |
+| Service call amortized inside one invocation                 | ~5.8 µs               |
+| Snippet replay per invocation                                | ~7.0 µs each          |
 | Per additional idle Sandbox (RSS)                            | ~1 KB                 |
 
-The Cranelift JIT runs once per machine and gem version — the compiled artifact persists in a `.cwasm` disk cache, so later processes deserialize in milliseconds. An idle Sandbox holds no wasm instance (the canonical boot state is baked into the artifact and instantiated per invocation), which is why a thousand idle tenants cost ~33 MB total. Under the default `gvl: :hold`, wasm work is GVL-serialized: aggregate throughput stays around 16k `#eval`/s regardless of Thread count, though Ruby-side `#eval` setup still overlaps. Opting a Sandbox into `gvl: :release` lifts that ceiling for compute-bound scripts (see [Concurrency](#concurrency)). A +10% regression on any SPEC-mandated benchmark blocks release.
+The Cranelift JIT runs once per machine and gem version — the compiled artifact persists in a `.cwasm` disk cache, so later processes deserialize in milliseconds. An idle Sandbox holds no wasm instance (the canonical boot state is baked into the artifact and instantiated per invocation), which is why a thousand idle tenants cost ~34 MB total. A +10% regression on any SPEC-mandated benchmark blocks release.
+
+#### What moves the ceiling
 
-Regexp is an opt-in capability gem, excluded from the default binary and the gated set; its throughput is tracked in a separate non-gated characterization (`#11` in [`benchmark/README.md`](benchmark/README.md)). There `=~` (~5 µs/match) costs about 4.5× `match?` (~1.1 µs), because `=~` eagerly builds the `MatchData` and match globals — prefer `match?` for boolean tests.
+| Choice | What it changes |
+|---|---|
+| `gvl: :hold` (default) | wasm work is GVL-serialized: aggregate throughput stays around 16k `#eval`/s regardless of Thread count, though Ruby-side `#eval` setup still overlaps |
+| `gvl: :release` | lifts that ceiling for compute-bound scripts (see [Concurrency](#concurrency)) |
+| `match?` over `=~` | `=~` (~5 µs/match) costs about 5× `match?` (~1.0 µs), because it eagerly builds the `MatchData` and match globals — prefer `match?` for boolean tests |
+
+Regexp is an opt-in capability gem, excluded from the default binary and the gated set; its throughput is tracked in a separate non-gated characterization (`#11` in [`benchmark/README.md`](benchmark/README.md)).
 
 ```bash
 bundle exec rake bench  # every gated regression benchmark (~5-8 min)
@@ -530,7 +588,12 @@ Building from source requires a WASI-capable Rust toolchain in addition to the s
 
 Bug reports and pull requests are welcome at <https://github.com/elct9620/kobako>. Please open an issue before starting on non-trivial changes so we can align on scope.
 
-Releases are automated with release-please across two tracks — the gem and the linked guest-crate group. The version rules, commit conventions, and how to cut each release live in [`docs/releasing.md`](docs/releasing.md).
+Releases are automated with release-please across two tracks; the version rules, commit conventions, and how to cut each release live in [`docs/releasing.md`](docs/releasing.md).
+
+| Track | What it ships | Tag |
+|---|---|---|
+| Gem | the Ruby gem, with the bundled `kobako.wasm` | `v*` |
+| Crates | the linked guest-crate group | `<component>-v*` |
 
 ## License
 

data/crates/kobako-runtime/CHANGELOG.md

@@ -1,5 +1,12 @@
 # Changelog
 
+## [0.17.0](https://github.com/elct9620/kobako/compare/kobako-runtime-v0.16.0...kobako-runtime-v0.17.0) (2026-09-20)
+
+
+### Miscellaneous Chores
+
+* **kobako-runtime:** Synchronize kobako crates versions
+
 ## [0.16.0](https://github.com/elct9620/kobako/compare/kobako-runtime-v0.15.0...kobako-runtime-v0.16.0) (2026-09-15)
 
 

data/crates/kobako-runtime/README.md

@@ -6,17 +6,14 @@ sandbox for running untrusted mruby scripts.
 
 A kobako host drives a Guest Binary through a wasm engine; this crate
 is the surface where the two meet, free of any engine or frontend
-type, so the engine stays swappable:
-
-- `runtime` — the `Runtime` trait: one guest invocation on a fresh
-  instance in, its observable `Snapshot` out
-- `snapshot` — the per-invocation observables: `Completion` (outcome
-  or trap), the two output `Capture`s, and resource `Usage`, uniform
-  across success and trap
-- `error` — the neutral failure channels: `Trap` (engine fault) and
-  `SetupError` (the invocation never started)
-- `dispatch` / `yielder` — the `DispatchHandler` and `Yielder` traits
-  a frontend supplies for guest→host dispatch and block-yield re-entry
+type, so the engine stays swappable.
+
+| Module | What it declares |
+|---|---|
+| `runtime` | the `Runtime` trait: one guest invocation on a fresh instance in, its observable `Snapshot` out |
+| `snapshot` | the per-invocation observables — `Completion` (outcome or trap), the two output `Capture`s, and resource `Usage`, uniform across success and trap |
+| `error` | the neutral failure channels: `Trap` (engine fault) and `SetupError` (the invocation never started) |
+| `dispatch` / `yielder` | the `DispatchHandler` and `Yielder` traits a frontend supplies for guest→host dispatch and block-yield re-entry |
 
 Engine implementations (such as `kobako-wasmtime`) implement
 `Runtime`; host frontends (such as the kobako Ruby gem's native ext)
@@ -26,7 +23,7 @@ map the neutral types onto their own language surface.
 
 ```toml
 [dependencies]
-kobako-runtime = "0.16.0" # x-release-please-version
+kobako-runtime = "0.17.0" # x-release-please-version
 ```
 
 ## License

data/crates/kobako-transport/CHANGELOG.md

@@ -1,5 +1,12 @@
 # Changelog
 
+## [0.17.0](https://github.com/elct9620/kobako/compare/kobako-transport-v0.16.0...kobako-transport-v0.17.0) (2026-09-20)
+
+
+### Miscellaneous Chores
+
+* **kobako-transport:** Synchronize kobako crates versions
+
 ## [0.16.0](https://github.com/elct9620/kobako/compare/kobako-transport-v0.15.0...kobako-transport-v0.16.0) (2026-09-15)
 
 

data/crates/kobako-transport/README.md

@@ -5,27 +5,34 @@ an in-process Wasm sandbox for running untrusted mruby scripts.
 
 kobako is assembled from three parts chosen independently: a host, a
 payload codec, and a guest. That works only because two things are the
-same in every assembly. This crate is both of them, and nothing else:
-
-- `envelope` — the **core envelope**, the outer frame each message rides
-  in: `Call` / `Reply` / `YieldReply` for a dispatch round-trip,
-  `Outcome` / `Panic` for how an invocation ended, `Run` / `Preamble` /
-  `Snippets` for what an invocation is handed, and the `ErrorRecord` a
-  guest failure carries
-- `abi` — the values a host and a guest must already agree on to
-  exchange a byte: the version, the packed `(ptr, len)` return layout,
-  the invocation-channel frame prefix, and the message size cap
-
-The envelope reads a message's routing fields and its ok-versus-fault
-tag without decoding a payload byte; everything the resolved method
-consumes rides through as an opaque `payload` this layer never reads.
-A decoded envelope borrows the buffer it came from, so that payload
-reaches its reader as a view rather than a copy.
-
-This crate depends on no other, and every kobako tier depends on it:
-`kobako-runtime` and `kobako-wasmtime` on the host, `kobako-core` and
-`kobako-mruby` in the guest, and any third-party engine, codec, or
-guest that composes against them.
+same in every assembly. This crate is both of them, and nothing else.
+
+| Module | What it fixes |
+|---|---|
+| `envelope` | the **core envelope**, the outer frame each message rides in: `Call` / `Reply` / `YieldReply` for a dispatch round-trip, `Outcome` / `Panic` for how an invocation ended, `Run` / `Preamble` / `Snippets` for what an invocation is handed, and the `ErrorRecord` a guest failure carries |
+| `abi` | the values a host and a guest must already agree on to exchange a byte: the version, the packed `(ptr, len)` return layout, the invocation-channel frame prefix, and the message size cap |
+
+## What the envelope does not read
+
+The envelope reads a message's routing fields and its ok-versus-fault tag
+without decoding a payload byte. Everything the resolved method consumes
+rides through opaque, and a decoded envelope borrows the buffer it came
+from, so that payload reaches its reader as a view rather than a copy.
+
+```text
+Call { method, payload }
+                  └── opaque here; read by whoever owns the schema
+```
+
+## Where it sits
+
+This crate depends on no other, and every kobako tier depends on it —
+including any third-party engine, codec, or guest composing against them.
+
+```text
+host   kobako-runtime · kobako-wasmtime ──┐
+guest  kobako-core · kobako-mruby ────────┴──> kobako-transport
+```
 
 The byte layout is specified in
 [`docs/wire/envelope.md`](https://github.com/elct9620/kobako/blob/main/docs/wire/envelope.md);
@@ -35,7 +42,7 @@ the golden vectors in this crate are derived from that document.
 
 ```toml
 [dependencies]
-kobako-transport = "0.16.0" # x-release-please-version
+kobako-transport = "0.17.0" # x-release-please-version
 ```
 
 ## License

data/crates/kobako-wasmtime/CHANGELOG.md

@@ -1,5 +1,12 @@
 # Changelog
 
+## [0.17.0](https://github.com/elct9620/kobako/compare/kobako-wasmtime-v0.16.0...kobako-wasmtime-v0.17.0) (2026-09-20)
+
+
+### Miscellaneous Chores
+
+* **kobako-wasmtime:** Synchronize kobako crates versions
+
 ## [0.16.0](https://github.com/elct9620/kobako/compare/kobako-wasmtime-v0.15.0...kobako-wasmtime-v0.16.0) (2026-09-15)
 
 

data/crates/kobako-wasmtime/README.md

@@ -6,16 +6,14 @@ The [wasmtime](https://wasmtime.dev) implementation of the
 
 `Driver` implements the contract's `Runtime` trait over wasmtime and
 owns every engine-bound mechanic, so frontends see only the neutral
-contract surface:
+contract surface.
 
-- process-wide Engine and compiled-Module caches with an on-disk AOT
-  (`.cwasm`) artifact cache keyed by Guest Binary content
-- a pre-linked `InstancePre` per guest path; every invocation runs on
-  a fresh instance and discards its Store afterwards
-- the epoch-based wall-clock timeout and the per-invocation
-  linear-memory cap
-- ambient denial: frozen WASI clocks and a constant RNG, so a guest
-  observes no real time and no real entropy
+| Mechanic | What the driver holds |
+|---|---|
+| Compilation | process-wide Engine and compiled-Module caches, with an on-disk AOT (`.cwasm`) artifact cache keyed by Guest Binary content |
+| Instantiation | a pre-linked `InstancePre` per guest path; every invocation runs on a fresh instance and discards its Store afterwards |
+| Bounds | the epoch-based wall-clock timeout and the per-invocation linear-memory cap |
+| Ambient denial | frozen WASI clocks and a constant RNG, so a guest observes no real time and no real entropy |
 
 The kobako Ruby gem's native ext is the first frontend; a Rust host
 SDK consumes the same surface.
@@ -24,7 +22,7 @@ SDK consumes the same surface.
 
 ```toml
 [dependencies]
-kobako-wasmtime = "0.16.0" # x-release-please-version
+kobako-wasmtime = "0.17.0" # x-release-please-version
 ```
 
 ## License

data/lib/kobako/version.rb

@@ -1,5 +1,5 @@
 # frozen_string_literal: true
 
 module Kobako
-  VERSION = "0.26.0"
+  VERSION = "0.27.0"
 end

data/rust-toolchain.toml

@@ -3,6 +3,10 @@
 # vendored wasi-sdk 33's libc.a supplies that symbol, so the two move together.
 # Bump this in lockstep with the wasi-sdk toolchain beni vendors
 # (`rake beni:build`, wired in the Rakefile's Beni::Tasks block).
+# The floor is 1.98: rustc strips an Apple binary with its own Mach-O writer,
+# and only from that release does the stripped string pool keep the alignment
+# dyld requires from macOS 26 onward — below it, `strip = true` in the release
+# profile yields an ext no dlopen accepts.
 # This file is the single source of the channel; the CI workflows read it.
 [toolchain]
 channel = "stable"

metadata

@@ -1,14 +1,14 @@
 --- !ruby/object:Gem::Specification
 name: kobako
 version: !ruby/object:Gem::Version
-  version: 0.26.0
+  version: 0.27.0
 platform: aarch64-linux
 authors:
 - Aotokitsuruya
 autorequire: 
 bindir: exe
 cert_chain: []
-date: 2026-09-15 00:00:00.000000000 Z
+date: 2026-09-21 00:00:00.000000000 Z
 dependencies:
 - !ruby/object:Gem::Dependency
   name: msgpack