Module Authoring

Integration modules are Rust packages that declare capabilities and expose typed actions, triggers, schemas, permissions, docs, and version metadata.

Package Contents

A publishable module package includes:

• Cargo.toml with cdylib output for WASM packaging.
• A manifest with ID, name, version, auth strategy, permissions, triggers, actions, schemas, docs URL, and compatibility metadata.
• Rust handlers for actions, trigger normalization, and optional connection checks.
• Generated .invoke/api.mgo MiniGo declarations.
• Generated .invoke/codemode-env.json CodeMode ABI mirror.
• Generated .invoke/extern_types.json for Rust-backed foreign types.
• Tests and fixtures that run through crates/core.

Host Boundary

Modules do not read environment variables, files, clocks, randomness, networks, or secrets directly. They request host capabilities through the core, and the core validates those calls against manifest-declared permissions.

WASM ABI

Modules export the InvokeTool module ABI through export_invoketool_module_abi!() from crates/module-sdk. The core rejects modules that cannot instantiate or whose ABI exports do not have the expected signatures:

• invoketool_module_abi_version() -> u32
• invoketool_module_alloc(len: u32) -> u32
• invoketool_module_dealloc(ptr: u32, len: u32) -> ()
• invoketool_module_invoke_action(ptr: u32, len: u32) -> u64

The current supported ABI version is 1. Allocation exports define the JSON envelope memory boundary for module action invocation, and the action export is the stable entrypoint the core probes before registering a module. The action entrypoint receives an ActionInvocation JSON envelope and returns a packed pointer/length to an ActionInvocationResult JSON envelope in module memory. The core can execute loaded integrations through this ABI and then validates the returned output against the same action schema used for CodeMode type generation. Provider host-call fulfillment is the next layer on the same boundary: modules that request HTTP, secrets, logs, metrics, state, or time still rely on the SDK host to satisfy those calls without exposing provider credentials to CodeMode. The module SDK uses the invoketool.invoketool_host_call import with a bounded response buffer:

invoketool_host_call(
  request_ptr: u32,
  request_len: u32,
  response_ptr: u32,
  response_capacity: u32,
) -> u32

The request is a serialized HostCall JSON envelope. The host writes a HostCallResult JSON envelope into the response buffer and returns the number of bytes written. The core maps that request to a manifest permission such as network:api.github.com, secret:github, log, or metrics before calling the SDK-provided host handler.

Integration Publishing

Integration bundles are versioned, checksum-addressed, and signed. The hosted marketplace stores install metadata and compatibility fields; SDKs verify the integration before loading it. Core install envelopes include the module manifest, generated MiniGo API snapshot, CodeMode ABI mirror, extern type snapshot, raw wasm_bytes, SHA-256 WASM checksum, manifest checksum, signature, and signing key ID so the runtime can reject tampered bytes before registration.

The signature is an HMAC-SHA256 hex digest over the normalized WASM checksum, a newline, and the normalized manifest checksum. The core accepts checksums with or without a sha256: prefix and rejects envelopes whose manifest, CodeMode snapshot, and extern snapshot IDs or versions do not match.

Before publishing, run node infra/scripts/validate-signing-policy.mjs and use the active INVOKETOOL_SIGNING_KEY_ID plus INVOKETOOL_SIGNING_SECRET from the release secret manager. The committed signing policy records key IDs and rotation windows only; HMAC key bytes must not be committed. The module packager also validates invoketool.module.json before signing: the manifest must reject unknown top-level fields, declare typed actions with input and output schemas, include explicit idempotency and retry flags, and keep auth, trigger, permission, and docs metadata aligned with the public manifest schema.

Integration loading also parses and instantiates the decoded WASM bytes. Invalid WebAssembly bytes, missing module memory, missing ABI exports, unsupported ABI versions, and ABI signature mismatches are rejected before registration. The core records imports, exports, memory count, function-body count, and the runtime ABI probe so SDKs can inspect the module shape through the WASM boundary before execution.