Takopi Architecture

Source analysis of takopi. Telegram bot dispatching coding agents to repos via Python plugin overlay.

Plugin overlay pattern: 222 custom lines via Python entry points extend upstream banteg/takopi (~20K installed) without forking - maintains compatibility while adding behavior
Auto-discovery: Shell script scans filesystem and generates TOML dynamically - zero-config project addition via convention
Graceful restart via exit(0): /reload exits cleanly, supervisor restarts, entrypoint re-scans - no complex state serialization
Minimal code surface: Delegates complexity to upstream, only adds routing layer - minimizes maintenance burden
Container-to-host bridge: /refresh uses dbus to trigger systemd from inside container - bridges bot with host infrastructure

222 lines of custom code on top of 20K upstream: This entire deployment is 4 Python plugins and a 27-line shell script. Everything else -- LLM integration, transport, routing -- is pip install takopi. You own almost nothing, and that's the point.
The plugin overlay pattern: Python entry points (pluggy) extend upstream without forking it. Upstream updates apply cleanly. No fork maintenance, no merge conflicts, no divergence.
Auto-discovery at startup: The entrypoint script scans a filesystem directory and generates TOML config dynamically. Adding a project = creating a directory. Zero-config project addition via pure convention.
Graceful restart via exit(0): /reload calls sys.exit(0). The container supervisor restarts, the entrypoint re-scans projects, and takopi starts fresh. No state serialization, no persistence layer, no complexity.
Container-to-host bridge via dbus: /refresh uses dbus to tell the host's systemd to restart a service -- from inside a container. Bridges the bot with host infrastructure without exposing the host.