@trusted-ai/xbot 0.1.0

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
@@ -0,0 +1,211 @@
1
+ # xbot Operations Guide
2
+
3
+ ## Product Modes
4
+
5
+ `xbot` is designed to cover three persistent use cases from the same runtime:
6
+
7
+ - AI assistant: interactive support over `email`, `slack`, `telegram`, `feishu`, `dingtalk`, `discord`, `matrix`, `whatsapp`, `qq`, `wecom`, `weixin`, or `mochat`
8
+ - autonomous software engineer: file edits, shell execution, tests, scheduled repo checks, GitHub/CI assistance through skills and MCP tools
9
+ - autonomous data analyst: web search, web fetch, scheduled reports, workspace report generation, and channel delivery
10
+
11
+ ## Core Building Blocks
12
+
13
+ The runtime already includes the main components required for unattended operation:
14
+
15
+ - persistent sessions
16
+ - long-term memory files
17
+ - shell/filesystem/web tools
18
+ - cron scheduling
19
+ - heartbeat review
20
+ - background subagents
21
+ - built-in skills
22
+ - OpenAI-compatible local or remote providers
23
+ - admin API/UI and metrics
24
+
25
+ Subagents:
26
+
27
+ - By default, subagents inherit the main task provider and model.
28
+ - Set `agents.subagents.model` and `agents.subagents.provider` to run subagents on a cheaper/faster model.
29
+ - Set `agents.subagents.apiBase`, or the matching `providers.<name>.apiBase`, to point subagents at a different OpenAI-compatible API server.
30
+ - If `agents.subagents.model` is empty, subagents keep using the main task model.
31
+
32
+ Memory behavior:
33
+
34
+ - `MEMORY.md` is permanent memory and is trimmed to `agents.defaults.memoryMaxBytes`
35
+ - finished user tasks are summarized into `MEMORY.md`
36
+ - `memorize` / `/memorize <text>` writes user-directed durable memory
37
+ - `clear` / `/clear` restores `HISTORY.md` to the default template for the workspace
38
+
39
+ ## Built-in Skills
40
+
41
+ Built-in skills live under `xbot/skills/` and are loaded by the runtime automatically.
42
+
43
+ Recommended built-ins:
44
+
45
+ - `workspace-operator`
46
+ - `software-engineer`
47
+ - `data-analyst`
48
+ - `github-cli`
49
+ - `github`
50
+ - `scheduled-ops`
51
+ - `memory` (always-on)
52
+ - `memory-hygiene` (always-on)
53
+ - `cron`
54
+ - `clawhub`
55
+ - `skill-creator`
56
+ - `summarize`
57
+ - `weather`
58
+ - `tmux`
59
+
60
+ The runtime injects always-on skills automatically and adds task-relevant skills when prompt keywords match their trigger metadata. Skills with unmet requirements (missing binaries, environment variables, or OS constraints) are marked as unavailable in the skills summary.
61
+
62
+ ### Skill Management CLI
63
+
64
+ ```bash
65
+ xbot skills list # List all skills with availability status
66
+ xbot skills init my-skill # Scaffold a new skill directory
67
+ ```
68
+
69
+ ## MCP for External Tooling
70
+
71
+ Use MCP when the built-in toolset is not enough.
72
+
73
+ Typical use cases:
74
+
75
+ - issue trackers
76
+ - browser automation
77
+ - database access
78
+ - internal APIs
79
+ - specialized data systems
80
+
81
+ Current support in `xbot`:
82
+
83
+ - MCP `stdio` transport
84
+ - startup validation for enabled servers
85
+ - MCP tools registered as normal native tools
86
+
87
+ Example:
88
+
89
+ ```json
90
+ {
91
+ "tools": {
92
+ "mcpServers": {
93
+ "browser": {
94
+ "enabled": true,
95
+ "type": "stdio",
96
+ "command": "npx",
97
+ "args": ["-y", "@modelcontextprotocol/server-playwright"],
98
+ "enabledTools": ["*"],
99
+ "toolTimeout": 45
100
+ }
101
+ }
102
+ }
103
+ }
104
+ ```
105
+
106
+ ## Admin UI
107
+
108
+ When `xbot run` is active, the admin UI is available at:
109
+
110
+ - `http://<host>:<port>/admin`
111
+
112
+ It shows:
113
+
114
+ - runtime uptime and message counts
115
+ - provider request counts and token totals
116
+ - average provider latency
117
+ - average prompt and generation throughput
118
+ - model identity, discovered model metadata, and known local model inventory
119
+ - CPU, memory, process, and best-effort GPU usage
120
+ - channel state
121
+ - session summaries
122
+ - cron jobs
123
+
124
+ Supported actions:
125
+
126
+ - start a channel
127
+ - stop a channel
128
+ - trigger heartbeat immediately
129
+
130
+ ## Metrics
131
+
132
+ The Prometheus endpoint is available at:
133
+
134
+ - `http://<host>:<port>/metrics`
135
+
136
+ Current metrics include:
137
+
138
+ - inbound and outbound message counters
139
+ - provider request, success, and failure counters
140
+ - total prompt and completion tokens
141
+ - average provider latency
142
+ - average prompt throughput
143
+ - average generation throughput
144
+
145
+ ## CLI Operations
146
+
147
+ Useful commands:
148
+
149
+ ```bash
150
+ cargo run -- status # Runtime status
151
+ cargo run -- sessions # List active sessions
152
+ cargo run -- jobs # List scheduled cron jobs
153
+ cargo run -- print-config # Print resolved config
154
+ cargo run -- channels list # List all available channels
155
+ cargo run -- channels status # Show enabled/disabled state per channel
156
+ cargo run -- channels login # Interactive login (Weixin QR code, WhatsApp bridge)
157
+ cargo run -- channels setup # Show setup instructions (how to get tokens/keys)
158
+ cargo run -- skills list # List skills with availability status
159
+ cargo run -- skills init NAME # Scaffold a new skill directory
160
+ cargo run -- config --provider # Interactive provider setup
161
+ cargo run -- config --channel # Interactive channel setup
162
+ ```
163
+
164
+ `status` resolves the current model/provider, inspects local system state, and prints the admin and metrics URLs.
165
+
166
+ ## 24/7 Deployment Pattern
167
+
168
+ Recommended production pattern:
169
+
170
+ 1. Use a stable workspace path under `~/.xbot/workspace` or a dedicated project directory.
171
+ 2. Use a process supervisor such as `systemd`, `launchd`, Docker, or Kubernetes.
172
+ 3. Point webhook-based channels at a stable public URL.
173
+ 4. Use a local provider such as Ollama or vLLM for long-running internal workloads when appropriate.
174
+ 5. Expose `/metrics` to your monitoring stack.
175
+ 6. Review `.xbot/HEARTBEAT.md` and cron jobs regularly so unattended work stays bounded.
176
+
177
+ ## Software Engineering Workflows
178
+
179
+ Recommended pattern:
180
+
181
+ 1. Put repository-specific constraints in `.xbot/XBOT.md`, `.xbot/TOOLS.md`, and workspace-local skills.
182
+ 2. Use the built-in `software-engineer` and `github-cli` skills.
183
+ 3. Add MCP servers for systems the bot needs but cannot reach with the default tools.
184
+ 4. Schedule repository health checks or report generation with cron.
185
+ 5. Review the admin UI for queue pressure, failures, and token usage.
186
+
187
+ ## Data Analysis Workflows
188
+
189
+ Recommended pattern:
190
+
191
+ 1. Use the built-in `data-analyst` skill.
192
+ 2. Save recurring reports into the workspace with timestamped filenames.
193
+ 3. Schedule recurring collection and report jobs with cron.
194
+ 4. Deliver summaries through channels and keep the detailed artifacts on disk.
195
+
196
+ ## Concurrency and Safety
197
+
198
+ - `max_concurrent_requests` (default 3) limits total concurrent inbound processing via a global semaphore.
199
+ - Per-session mutex ensures messages for the same session are serialized, preventing interleaved tool execution.
200
+ - Channel outbound delivery retries with exponential backoff (`send_max_retries`, default 3).
201
+
202
+ ## Reliability Notes
203
+
204
+ - Provider retries now only apply to transient failures.
205
+ - Local providers can run without API keys when recognized as local.
206
+ - OAuth providers (GitHub Copilot, OpenAI Codex) skip the API key requirement.
207
+ - Cursor provider requires explicit `apiBase` configuration.
208
+ - MCP configuration errors fail fast at startup.
209
+ - The admin API redacts secrets from the exposed config payload.
210
+ - Durable memory writes use the `memory-entry-writer` skill plus a short model summarization pass, with heuristic fallback if the provider summary fails.
211
+ - LLM-driven memory consolidation falls back to raw archive after 3 consecutive failures.