# hatchery-node kit (binary `gate4agent-node`)
Default build is the full kit. Feature `kit` (on by default) links:
1. `dig2browser` — path `../../../dig2browser` (local node browser machine; not the crates.io 0.5.0 tarball)
2. `mail4agent` — crates.io `0.4.8` (lib face; no sibling checkout needed)
3. session-restore — `claude-session-restore` and `codex-session-restore` 0.1.3 from crates.io; `grok-session-restore` and `kimi-session-restore` path deps because crates.io 0.1.3 is binary-only
4. kernel WireGuard — feature `wireguard`, `ip link add type wireguard` / `wg`. Node and C2 are peers (either side may dial). Not the UDP+ChaCha mesh underlay, not `open_wireguard_daemon_stub`, and not HQ.
Features: `m4a`, `d2b`, `session-restore`, `wireguard` (-> `gate4agent-node-core/wireguard`) and `memory` (a tool the agent calls; the node never starts a memory daemon). `kit` enables all of them and is the default. There is no light mode (no bare build); a subset can be built with `--no-default-features --features ...` for diagnostics.
The binary is still named `gate4agent-node`: agents see the g4a surface plus provider tools, nothing hatchery-specific.
Provider CLIs (`claude`, `codex`, `kimi`, `grok`) are packages. They are not copied credentials.
The node flag `--install-provider-clis` is **off by default**. When set (or when
`INSTALL_PROVIDER_CLIS=1` for the Docker/QEMU install script), the install path
checks PATH for each binary and downloads only the missing ones. It does not run
provider logins. Without the flag, nothing is downloaded. Mode 1's unit file does
not pass the flag.
## Mode 1 — service (implemented)
Entry point: the `gate4agent-node` binary from a default-feature build, installed as `deploy/node/gate4agent-node.service`.
The process links the four cores at startup (`force_link`) and starts the mail4agent mailbox on a background thread. It does not start Chrome or a tunnel unless the operator sets `GATE4AGENT_WG_*`. Those variables name a key *path* and the peer; the unit file does not contain secrets. If `ip link add type wireguard` fails, the process exits. It does not fall back to the mesh stub.
## Mode 2 — container (image build)
Entry point: `deploy/node/Dockerfile`, invoked by `deploy/node/docker-build.sh`. The image runs the same kit binary. `ENTRYPOINT` is `gate4agent-node`. No secret is copied into the image. Provider CLIs stay uninstalled unless `INSTALL_PROVIDER_CLIS=1` and `PROVIDER_CLI_INSTALL` is set at build time (`install-provider-clis.sh`).
## Mode 3 — QEMU guest
Entry point: `deploy/node/qemu-guest.sh`. It builds a minimal Alpine initramfs and boots it under QEMU with the same kit binary as mode 1. A virtio-9p mount (`kit`) carries the binary, its libraries, `ip`, and `wg`. The QEMU NIC is user-mode or a tap and is only the underlay. Kernel WireGuard is not a QEMU network. When `GATE4AGENT_WG_*` is set in the guest environment file, the node process creates the tunnel and dials C2 over it, the same as mode 1. The script does not provision secrets; it copies an operator-supplied environment file and the private-key file that file names.