Architecture snapshot / June 14, 2026

Columbia Console, as it exists today

A working local-first core and SvelteKit web client wrapped around Hermes, with the production hosting boundary still undecided.

Repository: highmatter/columbia-console / Revision: 5281319
53 core tests passing Typecheck clean 14 local commits unpublished Runtime currently stopped
!
The code is coherent; the deployment model is not settled.

The repository implements a core process beside Hermes, while the earlier architecture discussion selected a cloud control plane plus a separate connector. That is the main fork to resolve before hardening deployment.

Current implemented flow

Solid boxes exist in code. Dashed boxes are named future surfaces. The current development setup keeps all client-facing services on the laptop and reaches the Mac mini Hermes gateway over Tailscale.

Shipped

SvelteKit web app

Session list, transcript reader, lineage navigation, composer, live tool activity, markdown, responsive shell.

Deferred

Electron desktop

Planned thin shell around the same web UI.

Deferred

Expo mobile

Planned iPhone and iPad client with push notifications.

Typed HTTP
SSE + polling fallback
Shipped / localhost:8700

Columbia core

Effect v4 Node service. It is the only client-facing backend and keeps the Hermes credential server-side.

Typed APIHealth, sessions, messages, live run, chat, event stream
Mirror syncPolling, hot-session refresh, deletion reconciliation
Chat coordinatorHolds upstream SSE open and folds live run state
Event hub512-frame replay buffer and downstream SSE fan-out
Shipped / local disk

SQLite derived mirror

Disposable read model of sessions and messages. Hermes remains canonical.

Missing

Client authentication

Device pairing, per-device tokens, revocation, and production access policy.

REST polling
Chat SSE held open
Canonical runtime

Hermes gateway API

Sessions, transcripts, tools, runs, approvals, jobs, and agent execution.

Current dev path

Mac mini over Tailscale

100.92.102.43:8642, explicitly allowlisted by core configuration.

Production intent

Loopback co-location

Core and Hermes on the Mac mini, with Hermes bound only to 127.0.0.1.

ReadsCore mirrors Hermes sessions and transcripts into SQLite.
WritesThe web composer asks core to start a Hermes session chat stream.
RealtimeCore folds upstream events, then pushes live state and invalidations to clients.

Capability boundary

The first conversational slice is real. The broader control surface described by the product vision has not been implemented yet.

Working now
  • Session and transcript mirror
  • Lineage-aware navigation
  • Chat into existing sessions
  • Live text and tool activity
  • Replayable client SSE stream
  • Sanitized markdown rendering
Partially resolved
  • Production web serving model
  • Mac mini process supervision
  • Cloudflare or tailnet exposure
  • Externally started run visibility
  • Operational monitoring and logs
  • Documentation of the current slice
Not implemented
  • Device pairing and revocation
  • Create and fork sessions
  • Approvals and run controls
  • Jobs and configuration management
  • Tags, workstreams, pins, decisions
  • Native desktop and mobile apps

The topology fork

These are not minor deployment variants. They assign durable state, connectivity, authentication, offline behavior, and multi-agent coordination to different places.

What the repo implements

Core beside Hermes

The full Columbia backend and SQLite mirror run on the Mac mini. Clients reach that process through Tailscale or a Cloudflare Tunnel.

Clients>Tunnel>Core + DB + Hermes
Strengths
Simple authority boundary, low latency to Hermes, no cloud transcript copy, current code fits.
Costs
Mini availability gates everything, public access and auth terminate near the privileged host, multi-host coordination is harder.
Earlier agreed direction

Cloud control plane + connector

A Cloudflare-native control plane serves every client. A small outbound connector beside Hermes relays commands and derived state.

Clients>Cloud plane>Connector + Hermes
Strengths
Stable client endpoint, natural multi-agent model, offline queueing, cloud auth and notifications, connector stays outbound-only.
Costs
More protocol and state machinery, cloud projection semantics, conflict and reconnect design, current core must be split.

The decision underneath the decision

Is Columbia Console primarily a remote interface to one trusted Mac mini, or a durable cloud product that coordinates one or more Hermes hosts? The right topology follows from that answer.

  1. Decide the long-term product boundary.
  2. Name the canonical owner of Console-specific state.
  3. Then choose auth, offline, and deployment mechanics.

Observed runtime state

This confirms the architecture has handled real Columbia data, even though the services are not currently running.

Mirrored sessions
474
Real Mac mini data
Mirrored messages
20,892
SQLite read model
Last sync
Jun 12
4:12 PM Pacific
Current connectivity
Stopped
Tailscale and app services offline

Next architecture question

Should Columbia Console still be designed from day one as a cloud control plane for multiple Hermes agents, or has the product narrowed to a private, single-owner interface whose backend can live entirely beside Columbia on the Mac mini?