Canonical envelope
Normalize at the edge, preserve at the core
{
"event_id": "provider-native-id",
"transport": "telegram | slack | github",
"conversation": { "chat_id": "opaque", "thread_id": "opaque" },
"actor": { "id": "opaque", "display": "verbatim" },
"text": "verbatim inbound text",
"action": "launch | status | steer | pause | resume | interrupt | quit",
"reply_to": "optional provider id",
"received_at": "provider timestamp"
}Keep provider IDs and text verbatim; add derived routing fields without mutating the original payload. Persist the envelope before dispatch.
Adapter boundary
Three transports, one policy
Telegram: webhook or long-poll update → chat/thread mapping → signed action parser.
Slack: Events API plus slash-command acknowledgements → thread mapping → same action parser.
GitHub: issue/comment/webhook → repository/ref mapping → workflow launch or evidence reply.
Grok compatibility without Grok coupling
The useful bridge patterns are transport loops, concise routing, thread-aware context, retries, operator-visible status, and safe command parsing. Atomic++ keeps those behaviors but replaces ad-hoc process state with the canonical envelope, durable event IDs, authorization policy, workflow run IDs, and artifact-backed evidence. The existing Grok bridge remains outside this project and is not modified by this site.
Secret boundary. Provider tokens stay in the service environment or protected file, never in HTML, source, receipts, logs, URLs, or screenshots. The site documents the interface, not credentials.