Skip to content

Reference

Reference is look-up material, not a journey — you arrive here knowing what you need and leave with the exact type, route, key, or crate. Where the Concepts section explains why a plane exists and the Build and Operate sections walk you through doing something, Reference is the flat index you consult mid-task.

The remaining reference surfaces are being built out:

  • Wire contract — the Envelope / Payload event vocabulary and the ApomeshDaemon RPCs, generated from apomesh.proto. Until it lands, apomesh-protocol is the entry point.
  • REST API — the routes, request/response shapes, and SSE event names of the external JSON surface. Until it lands, see REST & SSE.
  • Configuration keys — the daemon config surface (profiles, listeners, routing, tenants, tool policy) as a looked-up key reference.
  • Glossary — the plane vocabulary and boundary types in one place, so a term met anywhere in the docs resolves to one definition.

Crate pages live under reference/crates/ and are grouped by the layer each crate belongs to — wire/protocol, substrate core and its implementation planes, orchestrator, worker, state stores, transports and applications, auth/config/support, tooling, verticals, and UI. A page is a map, not a mirror: it tells you the crate’s role, its place in the dependency graph, its curated public surface, and one worked example — rustdoc remains the exhaustive API listing.

Every workspace crate is classified, so nothing is silently missing. Each carries one of three states: documented (a reference page exists), planned (a page is owed — this is the standing documentation backlog), or internal (release or operator tooling reached through a guide rather than its own reference page). The classification is checked at build time, so a new crate cannot land unclassified and a documented entry whose page is missing fails the build.