Module kernels 

/kernels HTTP endpoints (roadmap feature #3 — server-side path).

Exposes the kernel registry to authenticated operators via three routes:

• POST /kernels — publish a signed [KernelManifest] + PTX text.
• GET /kernels — list manifests (PTX omitted).
• GET /kernels/{name}/{version} — resolve a manifest + PTX.

All three routes sit behind bearer_auth + tenant_scope (so the tenant extension is always present and every caller has cleared the token allowlist). The two GET routes admit any authenticated tenant. POST /kernels additionally requires the kernel-publish scope:

• Dev mode (TENSOR_WASM_API_TOKENS unset/empty) — every POST /kernels is rejected with 403 kernel_publish_disabled_in_dev_mode. Dev mode already grants every caller wildcard tenant scope, so allowing publish there would let unauthenticated traffic seed the registry. Operators who genuinely want a dev-time publish path must configure a token allowlist and opt the publishing token into TENSOR_WASM_API_KERNEL_PUBLISH_TOKENS.
• Production mode — the caller’s bearer token’s crate::rate_limit::TokenId must appear in KernelPublishTokens, the allowlist parsed from TENSOR_WASM_API_KERNEL_PUBLISH_TOKENS. A token in the main allowlist but not in the publish allowlist gets 403 kernel_publish_scope_required.

The server-side [InMemoryRegistry] is held in AppState::kernel_registry as an Option<Arc<dyn KernelRegistry>> and constructed at startup from the TENSOR_WASM_API_KERNEL_HMAC_KEY environment variable (64-hex 32-byte key). When the env var is unset, the routes return 503 kernel_registry_not_configured so client tools can detect feature availability without inspecting the URL surface.

URL syntax

axum 0.7 resolves path parameters via the colon-prefix syntax (:name, :version); the literal {name}/{version} shape used by the OpenAPI spec maps to the :name/:version axum route. The CLI issues GET /kernels/<name>/<version> (slash-separated) rather than the name@version form used by the in-memory key — the at-sign in a path segment is awkward to encode and most HTTP clients eagerly percent-encode it, so the canonical wire form takes the two-segment shape and the handler concatenates internally before the registry lookup. See docs/KERNEL-REGISTRY.md §“v0.4 rollout plan”.

Error envelope

Every failure surfaces the same {error: {kind, message}} shape the native routes use (see crate::routes::ApiError). The kinds introduced by this module:

kind	status	meaning
kernel_registry_not_configured	503	TENSOR_WASM_API_KERNEL_HMAC_KEY is unset; routes are wired but disabled
kernel_registry_storage_error	503	T35: disk-backed registry I/O error during publish
kernel_publish_disabled_in_dev_mode	403	POST /kernels rejected because the gateway is in dev mode (no tokens)
kernel_publish_scope_required	403	Caller’s bearer token is not in TENSOR_WASM_API_KERNEL_PUBLISH_TOKENS
publisher_not_allowed	403	T35: manifest.publisher is not in the registry’s publisher allowlist
bad_signature	403	HMAC verification under the configured key failed
digest_mismatch	400	BLAKE3(ptx_text) does not match manifest.digest
already_registered	409	A manifest with the same name@version is already present
invalid_request	400	Catch-all for other RegistryError variants (forward-compat)
not_found	404	The selector did not resolve to a registered manifest

Structs

ListKernelsQuery

Query parameters for GET /kernels.

ListKernelsResponse

Response body for GET /kernels.

PublishKernelRequest

Request body for POST /kernels.

ResolveKernelResponse

Response body for GET /kernels/{name}/{version}.

Functions

list_kernels

GET /kernels?offset=N&limit=M — list registered manifests.

publish_kernel

POST /kernels — publish a signed manifest + PTX text.

resolve_kernel

GET /kernels/{name}/{version} — resolve a manifest + PTX.