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

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.

m4a

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

m4a_gateway

Core’s m4a letters: core talks to sessions only through its own in-process m4a mailbox engine (the hub messenger). POST /v1/sessions/{id}/wake sends a letter from the operator mailbox to the session’s node naming the session; sessions close their run by sending run.close <run_id> <review|done|failed|cancelled> [branch] [commit] to the operator mailbox (door task.close_run stays as a fallback).

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.

routing

hq-core router: roles, presets, seats and a limit-aware fallback.

subservice

Subservice contract and a supervised-process implementation.

supervisor

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

tasks

hq-core work model: one task store (former P6 tasks + the harness kernel’s task/run ideas). Tasks carry a revision for compare-and-set and can be scoped to a role; a run binds a task to one real provider session on a node; sessions are recorded only when they are real provider conversations (drafts stay in hq-edge). Operator calls are idempotent by op_id. SQLite under the server data dir.

Functions

build_subservices

Build the subservices enabled by features and configuration.