rhema-cloudflare-code

3 Commits 1 Branch 0 Tags

3 Commits

Author	SHA1	Message	Date
vhaudiquet	09019b484d	fix(cloudflare-code): the host build carries the sandbox-http native transport ci / checks (push) Successful in 1m12s Details ci / test (push) Successful in 41s Details ci / wasm (push) Successful in 34s Details The published rhema-sandbox-http gates its reqwest code on the wasm target alone, so a featureless build compiles only on wasm — and the DO declares the crate featureless, because workerd has no sockets. On the host, where the neutral half compiles and tests, the feature is not optional: without it the crate cannot resolve `reqwest` and the workspace does not build. This workspace only ever saw the feature on, masked by member unification under --all-features; the extraction to registry deps removed the mask. The declaration splits by target: featureless on wasm (the fetch transport covers the protocol there), native on host. The crate's own cfg keeps the reqwest code native-only either way; the feature brings the dependency. The upstream gate repair — gating the code on the feature, not just the target — rides the rhema side.	2026-11-13 12:51:46 +01:00
vhaudiquet	8f9ea41857	build: lock the workspace to the published rhema 0.2.6 batch	2026-11-13 12:46:59 +01:00
vhaudiquet	c1059c23e0	build: the cloud frontend stands alone The Durable Object, the sandbox daemon, and their deploy assets leave the rhema workspace for a repository of their own. The DO was already a deployment artifact (publish = false, worker feature wasm-only), and rhema-sandbox-server's only consumer was the image beside it — both are product, not framework. The harness and the seam stay behind: rhema-cloud-agent and the sandbox family join the rhema repository's publish list, and this tree consumes them from crates.io at 0.2.6, the same arrangement the claw keeps its framework crates under. The sandboxd image build carries the fix its extraction needed: the old Dockerfile still staged the claw's workspace (claw and tools manifests, integrations globs, the vendored crossterm) and missed rhema-provider-registry's manifest entirely. The manifest stage is now this workspace's two members, fetched from the registry. Not yet buildable: the rhema 0.2.6 batch (rhema-sandbox, -local, -http, rhema-cloud-agent) must publish first — then one cargo check generates Cargo.lock and CI goes green.	2026-11-13 12:05:30 +01:00

Author

SHA1

Message

Date

vhaudiquet

09019b484d

fix(cloudflare-code): the host build carries the sandbox-http native transport

ci / checks (push) Successful in 1m12s

Details

ci / test (push) Successful in 41s

Details

ci / wasm (push) Successful in 34s

Details

The published rhema-sandbox-http gates its reqwest code on the wasm
target alone, so a featureless build compiles only on wasm — and the
DO declares the crate featureless, because workerd has no sockets.
On the host, where the neutral half compiles and tests, the feature
is not optional: without it the crate cannot resolve `reqwest` and
the workspace does not build. This workspace only ever saw the
feature on, masked by member unification under --all-features; the
extraction to registry deps removed the mask.

The declaration splits by target: featureless on wasm (the fetch
transport covers the protocol there), native on host. The crate's
own cfg keeps the reqwest code native-only either way; the feature
brings the dependency. The upstream gate repair — gating the code on
the feature, not just the target — rides the rhema side.

2026-11-13 12:51:46 +01:00

vhaudiquet

8f9ea41857

build: lock the workspace to the published rhema 0.2.6 batch

2026-11-13 12:46:59 +01:00

vhaudiquet

c1059c23e0

build: the cloud frontend stands alone

The Durable Object, the sandbox daemon, and their deploy assets
leave the rhema workspace for a repository of their own. The DO
was already a deployment artifact (publish = false, worker feature
wasm-only), and rhema-sandbox-server's only consumer was the image
beside it — both are product, not framework. The harness and the
seam stay behind: rhema-cloud-agent and the sandbox family join
the rhema repository's publish list, and this tree consumes them
from crates.io at 0.2.6, the same arrangement the claw keeps its
framework crates under.

The sandboxd image build carries the fix its extraction needed:
the old Dockerfile still staged the claw's workspace (claw and
tools manifests, integrations globs, the vendored crossterm) and
missed rhema-provider-registry's manifest entirely. The manifest
stage is now this workspace's two members, fetched from the
registry.

Not yet buildable: the rhema 0.2.6 batch (rhema-sandbox,
-local, -http, rhema-cloud-agent) must publish first — then one
cargo check generates Cargo.lock and CI goes green.

2026-11-13 12:05:30 +01:00