Crate hatchery_server 

Host for hatchery subservices. See deploy/README.md.

Re-exports

pub use config::ServerConfig;

pub use error::ServerError;

pub use subservice::State;

pub use subservice::Status;

pub use subservice::Subservice;

pub use supervisor::Supervisor;

Modules

config

Server configuration: an optional TOML file (HATCHERY_SERVER_CONFIG) with environment variables taking precedence. Addresses, binary paths and key variable names are never compiled in beyond loopback defaults; secrets are never stored here, only the names of the variables that hold them.

control

Loopback control endpoint (minimal HTTP/1.1, no framework).

drain_consumer

Core drain consumer (A2 / A3): core dials C2, drains one node stream, and answers on the same stream. C2 never dials core and never sees plaintext.

error

harness

Harness + observation host: supervises the hatchery-harness binary (the observation engine and store run inside it). Arguments come from the operator’s configuration; tokens stay in the environment the child inherits (GATE4AGENT_C2_TOKEN, operator token), never in arguments.

hub

P6: the hub behind the server control API: node calls forwarded by C2 and operator (HQ) calls for mail and tasks. All state lives under the data dir; admission is always read from the P2 ledger, never from the request.

kernel

hq-core task kernel: the former harness task/run/delivery kernel and the observation store, hosted in-process as libraries behind the hub (no separate hatchery-harness process, no legacy C2 control socket).

m4a

m4a subservice: the node-side messenger key vault (m4a-agent 0.4).

memory

memory4agent subservice (crates.io memory4agent 0.3, binary memory4agent-server). On demand only: the server never starts it by itself. It listens on loopback in 18200-18299, has no authentication, and is never published to WireGuard or outside. The child runs with a scrubbed environment so it never sees vault keys or tokens.

mesh_runtime

Production wiring for NodeOperatorMesh (A2).

messenger

P6: the hatchery messenger. It is the mail4agent mailbox engine (participants, addressing, rooms, delivery, acknowledgement; SQLite store) driven by the P2 provision ledger: a node is a participant exactly while the ledger says it is active and holds the mail grant, and room membership follows the ledger’s rooms. The engine’s rule is kept: a sender is never a field a caller fills in, it is the authenticated node the call arrives for.

node_controller

Core-side node controller (A2): g4a parsing lives here, not on C2.

node_sink

Production node-call sink on core (A2): applies node calls to the Hub.

operator_control

Core operator control (A2): same client wire as the former C2 control socket, but requests go through crate::node_controller::OperatorLink over the drain. C2 never sees this socket and never parses g4a.

provision

P2: provisioning of enrolled nodes on the server side.

subservice

Subservice contract and a supervised-process implementation.

supervisor

Lifecycle: start the autostart subservices, answer health, stop everything.

tasks

P6: minimal task manager. Tasks live in SQLite under the server data dir. An operator creates and assigns them; a node sees (and progresses) only the tasks assigned to it, and a task can be assigned only to a node whose ledger entry holds the tasks grant (trusted by default). The hub enforces that; this module is storage and state rules.

Functions

build_subservices

Build the subservices enabled by features and configuration.