Gateway

One runtime, multiple interfaces. The agent lives in the kernel; each gateway is a thin edge adapter over the same loop.

Shipped

TUI (Phase 1) — Bubble Tea interactive shell
Shared gateway chassis (Phase 2.B.2) — one gormes gateway runtime owns the manager loop, session mapping, and Telegram/Discord multi-channel boot path
Telegram adapter (Phase 2.B.1) — long-poll ingress, edit coalescing, session resume
Discord adapter (Phase 2.B.2) — mention-aware ingress and reply delivery on the shared chassis
Slack Socket Mode bot (Phase 2.B.3) — internal/slack has ingress, threaded reply flow, placeholder updates, session persistence, shared CommandRegistry parser wiring, the gateway.Channel shim, config/doctor loading, and cmd/gormes gateway registration
Priority connector wave (Phase 2.B.4, 2.B.10) — WhatsApp’s transport-neutral runtime, identity, send-gate, and reconnect contracts plus WeCom/WeiXin shared-bot seams now freeze ingress/reply behavior ahead of full transports
slash-command registry (Phase 2.F.1) — one canonical command registry drives parsing, help text, Telegram menus, and Slack subcommands
SessionContext prompt injection + delivery target parsing (Phase 2.B.5) — stable Current Session Context block, typed --deliver parsing, and a deterministic Gateway stream consumer contract
HOOK.yaml loading + BOOT.md startup hook (Phase 2.F.2) — live hook manifest discovery, per-event registry hooks, and non-blocking BOOT.md startup execution
Cron delivery bridge (Phase 2.D) — scheduled runs, SQLite cron_runs audit, CRON.md mirror, and Heartbeat [SYSTEM:] / [SILENT] delivery rules
Operator automation runners (Phase 2.D / Phase 1.C) — scripts/gormes-architecture-planner-tasks-manager.sh, scripts/documentation-improver.sh, and scripts/landingpage-improver.sh now emit context bundles, reports, state files, validation logs, and verbose progress checkpoints under .codex/. The auto-codexu orchestrator runs them as interleaved companions (planner roughly every four cycles; doc improver every six productive cycles; landingpage improver daily), writes staged audit cursor/report artifacts with minimal ledger counts under ~/.cache/gormes-orchestrator-audit/, and supports a 24-hour activity summary via scripts/orchestrator/daily-digest.sh. Legacy service-health, integration-head, companion-status, and token/cost audit telemetry are not yet reproduced in the Go audit. Wrapper compatibility and high-parallelism false-failure handling remain open under 1.C.

Planned

Remaining priority connector runtime work — Slack’s 2.B.3 shared-chassis contract is closed; any richer ack UX, deeper thread behavior, or media/attachment polish should be a new small backlog row. WhatsApp’s 2.B.4 contracts are closed and any live bridge/native startup or QR UX should be a new small backlog row; WeChat still needs WeCom/WeiXin transport/bootstrap code; Discord Forum Channels still need thread lifecycle plus media/outbound polish. See §7 Subsystem Inventory.
Paused Phase 7 connector backlog — Signal, Email/SMS, Matrix/Mattermost, Webhook, BlueBubbles/HomeAssistant, Feishu, DingTalk, and QQ remain tracked but are no longer Phase 2 execution priorities.
Phase 2.F.3–2.F.4 — adapter startup cleanup, active-turn follow-up/late-arrival drain policy, drain-timeout resume recovery, pairing persistence, approval/rate-limit semantics, status JSON/PID validation, token-scoped credential locks, /restart takeover/dedup markers, channel lifecycle writers, home-channel routing, channel/contact directory refresh, mirror surfaces, and sticker-cache equivalents.
Telegram fresh-final streaming — Hermes b16f9d43 sends a fresh final Telegram message for long-lived streamed previews so visible timestamps reflect completion time. Gormes tracks this as a shared gateway eligibility helper, a shared send/delete fallback, then Telegram config + deleteMessage wiring under Phase 2.B.5.
Native API server replacement — Phase 1 still consumes Python’s api_server; Phase 5.Q must port the OpenAI-compatible chat-completions, Responses API, run-event SSE, detailed health, and cron-admin HTTP surfaces over the Go runtime before Python leaves the gateway path.

Why this matters

Agents that only live in a terminal are academic. Agents that live where the operator lives — on their phone, in their team chat — are infrastructure. Gormes’s split-binary-then-unified design lets each adapter ship independently without dragging the TUI’s deps.

Donor pointers

When implementing a new gateway slice, route through the gormes-references skill (docs/development-skills/gormes-references/SKILL.md) before re-deriving a shape. The most useful Go donors for gateway/runtime work live under references/go-agent-os/:

Gateway problem	Donor file
Adapter chassis with explicit dependency layering	`nanobot/pkg/runtime/runtime.go`
Tool service with before/after hooks (slash + tool dispatch)	`nanobot/pkg/tools/service.go`, `nanobot/pkg/tools/flows.go`
Await-user-reply / pause-and-resume across active turns	`trpc-agent-go/agent/await_user_reply.go`
Provider/agent callback pipeline (turn lifecycle hooks)	`trpc-agent-go/model/callbacks.go`, `trpc-agent-go/agent/callbacks.go`
Cancellable session-scoped workers (fan-out without leaks)	`nanobot/pkg/runtime/runtime.go` plus `trpc-agent-go/agent/await_user_reply.go`
Telegram-safe error sanitization, raw HTML truncation	`nanobot/pkg/agents/truncate.go`

For PicoClaw’s per-channel adapter inventory, see Gateway Donor Map. For provider/auth/streaming/quota/retry behavior visible at the gateway edge, use the gormes-provider-parity skill and references/go-agent-os/GORMES-PROVIDER-PATTERN-REFERENCES.md instead.

See Phase 2 for the Gateway ledger.