Architecture

How PearData is structured: agent pipeline, HyperDHT control plane, optional REST, HyperDB warm store, and desktop QVAC. Peer-to-peer by design — no open ports required for remote monitoring.

Planes

Plane	Role
Control / metadata	Handshake, catalog, alerts config, invites, jobs, ACL, Data Manager
High-frequency metrics	1s collect → ring buffers → `push:metrics` + `queryData`
Anomaly / health	Threshold engine → `push:anomaly` / `push:alert` + `push:health`
Local REST (optional)	`/api/v1\|v2\|v3` on `127.0.0.1:18888`
Local AI (desktop)	QVAC tab + tools; models never load on the agent

Agent pipeline

collector (1s) → store (hot/warm memory) → anomaly engine
                 ↘ HyperDB warm flush
                 ↘ protomux-rpc pushes to subscribed clients

Entry: server/server.js / bin/peardata-server.mjs. Collectors read /proc and optional Docker/cgroup metrics when enabled.

Desktop

Pear (index.js) or Electron (electron/main.cjs) loads the HTML shell. Connection stack in client/*. Views: Overview, Charts, Dashboard, Processes, Alerts, QVAC, Logs, Fleet, Connect, Settings.

QVAC

On-device inference via @qvac/sdk (Bare worker). Tools call existing agent RPCs. Multi-agent specialists run dynamically for broad investigations; UI embeds swarm cards in the chat transcript. Packaging notes: portable worker entry, cross-host bare-runtime installs for CI clients.

Storage

Hot path stays in memory. Warm history via HyperDB/Corestore with retention.json, auto-prune, and Data Manager UI (admin). Optional Hyperswarm for linked peer warm pull.