How to reverse engineer the clawdbot app?

reverse engineer this app

Here’s a quick “reverse-engineered” tour of Clawdbot, rooted in the repository’s sources so you can follow the wires yourself.

##1. Core “control plane” (Gateway, CLI, runtime)

• README.md (intro & “How it works” diagram) explains that Clawdbot is a single-node Gateway that exposes a WebSocket control plane (ws://127.0.0.1:18789) and lets CLI/agents/nodes attach to it while it brokers messages to real-world channels like WhatsApp, Telegram, Slack, etc. (see the architecture diagram in README.md and the “Highlights” section listing gateway, CLI, multi-channel inbox, Canvas, nodes, etc.).
• src/index.ts is the actual entry point for clawdbot …. It boots the runtime (dotenv/env normalization, runtime guard, CLI help setup), exports helper utilities, and ultimately calls buildProgram() from src/cli/program/build-program.ts, which wires up the commander-based CLI surface (gateway, agent, wizard, doctor…).
• src/gateway contains all the server/runtime logic for that control plane: authentication, WebSocket handling, session management, hooks, runtime config/state, tailscale exposure, cron/health endpoints, and the node/agent tooling that talks to it. The server/… subdirectory implements TLS, HTTP/WebSocket listeners, and plugins. This is the heart that maintains sessions, routes events, and exposes telemetry/log streams.

##2. Channels + agents/skills

• src/channels (and related per-channel directories in src/discord, src/slack, etc.) house adapters that connect the Gateway to external messaging surfaces (Baileys for WhatsApp, grammY for Telegram, discord.js for Discord, etc.) as mentioned in the README’s “Channels” section. Each channel folder implements events/filters/routing logic that speaks the Gateway’s internal protocol.
• src/agents, src/skills, and the skills/ folder implement the “Pi agent runtime” and skill tooling referenced in README.md. Agents are multi-agent executors that act on instructions, hook into streaming/blocks, and call skills (browser control, Canvas/A2UI, nodes, cron jobs, etc.).
• src/tools, src/nodes, src/platforms etc. implement the first-class tooling mentioned under “Highlights” (browser automation, Canvas, nodes, voice wake, talk mode).

##3. Supporting systems

• apps/ and ui/ contain the packaged macOS/iOS/Android/node UIs and the Control UI’s web front-end that the Gateway serves (see README.md’s “Control UI” highlight and the docs under docs/web/).
• docs/ is the living documentation referenced by the README (gateway, channels, nodes, skills, automation, security, etc.). It mirrors how the codebase is organized, so you can cross-reference a doc page (e.g., docs/gateway/) with src/gateway/ to follow the implementation.
• scripts/, pnpm-workspace.yaml, and package.json orchestrate building, bundling, and packaging for dev (PNPM scripts, TSX dev server, building UI, etc.). Running pnpm build (per README “From source”) compiles TS to dist/, which you can run with Node ≥22.

##4. Data/Message flow (per README diagram & source)

1. External channel event (WhatsApp/Telegram/Slack/Discord/GoogleChat/Signal/iMessage/BlueBubbles/MSTeams/Matrix/Zalo/Zalo Personal/WebChat, etc.)
2. Routed into Gateway (src/gateway) via HTTP/websocket/channel adapters.
3. Gateway maintains sessions/presence/chronos and broadcasts events to:
   • Pi agents (multi-agent runtime, probably under src/agents + src/gateway/client).
   • CLI/UI/nodes (via WebSocket/Tailscale exposures and direct CLI commands).
4. Agents talk to models (Anthropic/OpenAI, see docs for model config) and tools/skills/nodes to craft a response.
5. Gateway sends replies back through the channel adapter to the user.
6. Supporting tooling (streaming, cron, webhooks, skills, Canvas) plugs into this loop.

##5. Dev workflow highlights

• pnpm gateway:watch (per README) runs the Gateway in watch mode (see scripts or src/cli).
• pnpm ui:build builds the Control UI; ui/ uses Vite (see ui/vite.config.ts).
• Extensive tests cover gateway behavior (src/gateway/*.test.ts, test/…), channel contracts, CLI helpers, and automation flows.

If you need a deeper dive (e.g., tracing a specific channel or following how sessions are stored), let me know which subsystem should be unwrapped next.