# LaodingBot (MVP)

Go-based personal Telegram Agent with:

- Telegram polling transport
- OpenAI-compatible LLM client
- SQLite conversation memory + simple compression
- Tool registry with built-in `file`, `shell`, and `git` tools
- Default-deny security policy via allowlists
- Soul markdown loading for bot personality
- Skills markdown loading for capability context
- ReAct decision loop with automatic tool execution

Now supports mutually exclusive message channels:

- `telegram` (long polling)
- `feishu` (official SDK websocket long connection)
- `webui` (HTTP + SSE, default `:8090`)

## Quick Start

1. Prepare env variables (see `configs/env.sample`).
	- The app auto-loads `configs/env` (or `.env`) if present.
	- You can also set `CONFIG_ENV_FILE=/path/to/env`.
	- Process environment variables override file values.
2. Choose exactly one channel with `MESSAGE_CHANNEL=telegram|feishu|webui`.
	- If `telegram`: set `TELEGRAM_BOT_TOKEN`, keep `FEISHU_*` empty.
	- If `feishu`: set `FEISHU_APP_ID` and `FEISHU_APP_SECRET`, keep `TELEGRAM_BOT_TOKEN` empty.
	- If `webui`: set `WEBUI_LISTEN_ADDR` (default `:8090`).
3. Set log level with `LOG_LEVEL=debug|info|warn|error`.
	- To inspect full skill/tool execution content and detailed ReAct step traces, use `LOG_LEVEL=debug`.
4. Configure knowledge and reasoning:
	- `SOUL_PATH` for bot personality markdown.
	- `SKILLS_DIR` for skills markdown directory.
	- `REACT_MAX_STEPS` for maximum ReAct steps.
5. Create runtime directories:

```bash
mkdir -p data workspace
```

6. Run:

```bash
go mod tidy
go run ./cmd/bot
```

## Telegram Usage

- Normal text enters unified agent pipeline:
	1. Receive message and load recent memory context
	2. Match relevant skill(s) from `skills/`
	3. If no skill matched, respond via direct LLM
	4. If skill matched, run ReAct and call tools (`shell` / `file` / `git`) only when needed
	5. Return final answer
- No `/tool ...` command is required for normal use.

## Feishu Usage

- Bot uses Feishu official SDK long connection (`ws`) to subscribe `im.message.receive_v1` text events.
- Received text is forwarded to the same agent pipeline and replied back to the same chat.

## Knowledge Files

- Soul file default path: `bot_context/soul.md`
- Skills directory default path: `skills/`
- Skill format uses subdirectories: `skills/<skill_name>/skill.md`

## Docker Build And Run

### Required Files And Folders

Before building/running with Docker, ensure these exist:

- `Dockerfile`
- `docker-compose.yaml`
- `workspace/agent_runtime/configs/env`
- `workspace/agent_runtime/bot_context/soul.md`
- `workspace/agent_runtime/skills/`
- `workspace/agent_runtime/data/`
- `workspace/agent_runtime/workspace/`

Quick bootstrap command:

```bash
mkdir -p workspace/agent_runtime/{configs,bot_context,skills,data,workspace}
cp -n configs/env.sample workspace/agent_runtime/configs/env
cp -n bot_context/soul.md workspace/agent_runtime/bot_context/soul.md
cp -rn skills/* workspace/agent_runtime/skills/
```

Minimum env config in `workspace/agent_runtime/configs/env`:

```env
MESSAGE_CHANNEL=webui
WEBUI_LISTEN_ADDR=:8090
LLM_API_KEY=your_api_key
```

`docker-compose.yaml` already mounts `./workspace/agent_runtime` into the container, so host-side data is persistent.

### Build Docker Image

```bash
docker build -t laodingbot:latest .
```

### Run With Docker (Single Container)

```bash
docker run --rm -d \
	--name laodingbot \
	-p 8090:8090 \
	--env-file ./workspace/agent_runtime/configs/env \
	-e MESSAGE_CHANNEL=webui \
	-e WEBUI_LISTEN_ADDR=:8090 \
	-e AGENT_WORKSPACE_DIR=/app/workspace/agent_runtime \
	-v "$(pwd)/workspace/agent_runtime:/app/workspace/agent_runtime" \
	laodingbot:latest
```

### Run With Docker Compose

Build and start:

```bash
docker compose up -d --build
```

View logs:

```bash
docker compose logs -f laodingbot
```

Stop and remove:

```bash
docker compose down
```

After startup, open WebUI at `http://localhost:8090`.

## Security Notes

- `shell` only allows commands listed in `ALLOWED_COMMANDS`.
- `file` only allows paths inside `ALLOWED_DIRS`.
- `git` only allows common git subcommands and runs inside `WORK_DIR`.
- Working directory for shell is limited by `WORK_DIR`.

## Next Iteration

- Add skill runtime (process-level hot-plug via RPC)
- Add bootstrap pipeline (generate -> vet/test -> sandbox run -> register)
- Add approval gate for risky commands