MessageFoundry isn't one program — it's a small toolkit arranged around the engine and its localhost API. Each tool is its own process you run on its own, and every UI is just a client of that one API. Here's the whole set.
The engine is the only long-running service — and the only thing that touches the store. Everything else talks to it over the one localhost API; the tee relay sits in front.
The headless runtime: it owns the store, runs your Connections, Routers, and Handlers through the staged queue, and exposes the localhost HTTP/WebSocket API. Everything else talks to this. Runs as a Windows service via NSSM.
One binary, many jobs: serve, init (scaffold a config repo), validate / dryrun / check (the commit/CI gate), connection (edit connections.toml), and generate (synthetic HL7), plus key & audit ops. The introspection commands touch no network — git hooks and the VS Code extension shell them.
The operator GUI: a connection dashboard, a message browser with each message's disposition, delivery/audit trail, and one-click replay, an HL7 parse-tree viewer, and user and session management. A pure API client — it never touches the database.
The authoring surface: a New Route Wizard, validate-on-save, a Test Bench that dry-runs .hl7 files with before/after diffs, Stage → Promote to a running engine, and an HL7-aware @messagefoundry AI chat participant. It shells the CLI's introspection commands.
Exercises a running engine with synthetic, PHI-free traffic: Send / Receive / File / Compose / Monitor tabs (inject ACK faults, malformed messages, delivery failures), headless CI scenarios that assert dispositions, and a separate load-testing engine with tunable profiles (warmup → ramp → soak) and an SLO report.
A migration de-risking tool: sit it in front of a legacy engine and a shadow MessageFoundry, ACK on receipt, and forward the same bytes to both — so you can compare output before cutover (rollback is just stopping the relay). Test and synthetic data only; not PHI-hardened.
One contract, many clients. The engine is the only long-running service — and the only thing that touches the store. The console, the extension, and the harness are separate processes that drive or observe it over that one localhost API; the tee relay sits in front. And because that one API is the only door in — the console can't import the engine or reach the store directly — authentication, RBAC, and audit sit at a single choke point nothing slips past. That's the architecture, made concrete.
