Compare commits
10 commits
27e26daccf
...
b681041046
| Author | SHA1 | Date | |
|---|---|---|---|
| b681041046 | |||
| de004aa82b | |||
| 25355f7066 | |||
| 89eef18cf6 | |||
| d1dec9fe29 | |||
| 7de665d2c8 | |||
| 43f66ff1e6 | |||
| 91a6710c52 | |||
| 0f803a2c7f | |||
| aec5ca5883 |
135 changed files with 6845 additions and 962 deletions
31
.forgejo/workflows/botbook.yaml
Normal file
31
.forgejo/workflows/botbook.yaml
Normal file
|
|
@ -0,0 +1,31 @@
|
|||
name: GBCI
|
||||
|
||||
on:
|
||||
push:
|
||||
branches: ["main"]
|
||||
pull_request:
|
||||
branches: ["main"]
|
||||
|
||||
jobs:
|
||||
build:
|
||||
runs-on: gbo
|
||||
|
||||
steps:
|
||||
- name: Disable SSL verification (temporary)
|
||||
run: git config --global http.sslVerify false
|
||||
|
||||
- uses: actions/checkout@v4
|
||||
|
||||
- name: Install mdBook
|
||||
run: |
|
||||
if ! command -v mdbook &> /dev/null; then
|
||||
cargo install mdbook
|
||||
fi
|
||||
|
||||
- name: Build documentation
|
||||
run: mdbook build
|
||||
|
||||
- name: Deploy documentation
|
||||
run: |
|
||||
sudo cp -r ./book/* /opt/gbo/tenants/pragmatismo/proxy/data/websites/docs.pragmatismo.com.br/
|
||||
sudo chown -R www-data:www-data /opt/gbo/tenants/pragmatismo/proxy/data/websites/docs.pragmatismo.com.br/
|
||||
236
PROMPT.md
236
PROMPT.md
|
|
@ -1,7 +1,7 @@
|
|||
# BotBook Development Prompt Guide
|
||||
# botbook Development Prompt Guide
|
||||
|
||||
**Version:** 6.1.0
|
||||
**Purpose:** LLM context for BotBook documentation development
|
||||
**Purpose:** LLM context for botbook documentation development
|
||||
|
||||
---
|
||||
|
||||
|
|
@ -122,7 +122,7 @@ SET_HEADER ' WRONG!
|
|||
|
||||
## Project Overview
|
||||
|
||||
BotBook is the **mdBook-based documentation** for the General Bots platform. It provides comprehensive guides, tutorials, and API references for users and developers.
|
||||
botbook is the **mdBook-based documentation** for the General Bots platform. It provides comprehensive guides, tutorials, and API references for users and developers.
|
||||
|
||||
### Workspace Position
|
||||
|
||||
|
|
@ -136,7 +136,7 @@ botmodels/ # Data models visualization
|
|||
botplugin/ # Browser extension
|
||||
```
|
||||
|
||||
### What BotBook Provides
|
||||
### What botbook Provides
|
||||
|
||||
- **User Guides**: Getting started, installation, quick start
|
||||
- **BASIC Reference**: Keywords, syntax, examples
|
||||
|
|
@ -328,18 +328,135 @@ When documenting features, verify against actual source:
|
|||
|
||||
---
|
||||
|
||||
## Diagram Guidelines
|
||||
## NO ASCII DIAGRAMS — MANDATORY
|
||||
|
||||
For SVG diagrams in `src/assets/`:
|
||||
**NEVER use ASCII art diagrams in documentation. ALL diagrams must be SVG.**
|
||||
|
||||
### Prohibited ASCII Patterns
|
||||
|
||||
```
|
||||
- Transparent background
|
||||
- Dual-theme support (light/dark CSS)
|
||||
- Width: 1040-1400px
|
||||
- Font: Arial, sans-serif
|
||||
- Colors: Blue #4A90E2, Orange #F5A623, Purple #BD10E0, Green #7ED321
|
||||
❌ NEVER USE:
|
||||
┌─────────┐ ╔═══════╗ +-------+
|
||||
│ Box │ ║ Box ║ | Box |
|
||||
└─────────┘ ╚═══════╝ +-------+
|
||||
|
||||
├── folder/ │ → ▶ ──►
|
||||
│ └── file ▼ ← ◀ ◄──
|
||||
```
|
||||
|
||||
### What to Use Instead
|
||||
|
||||
| Instead of... | Use... |
|
||||
|---------------|--------|
|
||||
| ASCII box diagrams | SVG diagrams in `assets/` |
|
||||
| ASCII flow charts | SVG with arrows and boxes |
|
||||
| ASCII directory trees | Markdown tables or SVG |
|
||||
| ASCII tables with borders | Markdown tables |
|
||||
| ASCII progress indicators | SVG or text description |
|
||||
|
||||
### Directory Trees → Tables
|
||||
|
||||
```markdown
|
||||
❌ WRONG:
|
||||
mybot.gbai/
|
||||
├── mybot.gbdialog/
|
||||
│ └── start.bas
|
||||
└── mybot.gbot/
|
||||
└── config.csv
|
||||
|
||||
✅ CORRECT:
|
||||
| Path | Description |
|
||||
|------|-------------|
|
||||
| `mybot.gbai/` | Root package |
|
||||
| `mybot.gbdialog/` | BASIC scripts |
|
||||
| `mybot.gbdialog/start.bas` | Entry point |
|
||||
| `mybot.gbot/` | Configuration |
|
||||
| `mybot.gbot/config.csv` | Bot settings |
|
||||
```
|
||||
|
||||
### Rationale
|
||||
|
||||
- ASCII breaks in different fonts/editors
|
||||
- Not accessible for screen readers
|
||||
- Cannot adapt to dark/light themes
|
||||
- Looks unprofessional in modern docs
|
||||
- SVGs scale perfectly at any size
|
||||
|
||||
---
|
||||
|
||||
## SVG Diagram Guidelines — Theme Transparency
|
||||
|
||||
All SVG diagrams MUST be theme-agnostic and work with light/dark modes.
|
||||
|
||||
### Required Structure
|
||||
|
||||
Every SVG must include:
|
||||
|
||||
1. **CSS classes for text** (not hardcoded colors)
|
||||
2. **Dark mode media query** in `<style>` block
|
||||
3. **Standard gradient definitions** in `<defs>`
|
||||
|
||||
### Required CSS Block
|
||||
|
||||
```xml
|
||||
<style>
|
||||
.title-text { fill: #1E1B4B; font-family: -apple-system, BlinkMacSystemFont, 'Segoe UI', Roboto, sans-serif; }
|
||||
.main-text { fill: #334155; font-family: -apple-system, BlinkMacSystemFont, 'Segoe UI', Roboto, sans-serif; }
|
||||
.secondary-text { fill: #64748B; font-family: -apple-system, BlinkMacSystemFont, 'Segoe UI', Roboto, sans-serif; }
|
||||
.white-text { fill: #FFFFFF; font-family: -apple-system, BlinkMacSystemFont, 'Segoe UI', Roboto, sans-serif; }
|
||||
.mono-text { fill: #475569; font-family: 'SF Mono', 'Fira Code', Consolas, monospace; }
|
||||
|
||||
@media (prefers-color-scheme: dark) {
|
||||
.title-text { fill: #F1F5F9; }
|
||||
.main-text { fill: #E2E8F0; }
|
||||
.secondary-text { fill: #94A3B8; }
|
||||
.mono-text { fill: #CBD5E1; }
|
||||
}
|
||||
</style>
|
||||
```
|
||||
|
||||
### Standard Gradients (use these IDs)
|
||||
|
||||
| Gradient ID | Colors | Purpose |
|
||||
|-------------|--------|---------|
|
||||
| `primaryGrad` | `#6366F1` → `#8B5CF6` | Primary/purple elements |
|
||||
| `cyanGrad` | `#06B6D4` → `#0EA5E9` | Cyan/info elements |
|
||||
| `greenGrad` | `#10B981` → `#34D399` | Success/green elements |
|
||||
| `orangeGrad` | `#F59E0B` → `#FBBF24` | Warning/orange elements |
|
||||
|
||||
### Background Rules
|
||||
|
||||
- Use `fill="#FAFBFC"` for main background (not pure white)
|
||||
- Add dot pattern overlay: `fill="url(#dots)"` with `opacity="0.08"`
|
||||
- Cards use `fill="#FFFFFF"` with `stroke="#E2E8F0"` for definition
|
||||
- Use `filter="url(#cardShadow)"` for card depth
|
||||
|
||||
### DO NOT
|
||||
|
||||
- ❌ Hardcode text colors without CSS class
|
||||
- ❌ Use pure black (`#000000`) for text
|
||||
- ❌ Forget the `@media (prefers-color-scheme: dark)` block
|
||||
- ❌ Create new gradient IDs when standard ones exist
|
||||
- ❌ Use ASCII art diagrams when SVG is appropriate
|
||||
|
||||
### DO
|
||||
|
||||
- ✅ Use CSS classes for ALL text elements
|
||||
- ✅ Include dark mode media query in every SVG
|
||||
- ✅ Use standard gradient IDs consistently
|
||||
- ✅ Test SVGs in both light and dark browser modes
|
||||
- ✅ Convert ASCII diagrams to proper SVGs
|
||||
- ✅ Place SVGs in `src/assets/chapter-XX/` directories
|
||||
|
||||
### Dimensions
|
||||
|
||||
- Width: 600-1200px (responsive)
|
||||
- Use `style="max-width: 100%; height: auto;"` when embedding
|
||||
|
||||
### Reference
|
||||
|
||||
See `src/16-appendix-docs-style/svg.md` for complete guidelines.
|
||||
|
||||
---
|
||||
|
||||
## Translation Workflow
|
||||
|
|
@ -463,3 +580,100 @@ HEAR variable
|
|||
SEND MAIL to, subject, body, attachments
|
||||
SEND TEMPLATE recipients, template, variables
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Conversation Examples (WhatsApp Style)
|
||||
|
||||
All conversation examples throughout the book use the WhatsApp-style HTML format. This provides a familiar, visually consistent representation of bot interactions.
|
||||
|
||||
### Standard Format
|
||||
|
||||
```html
|
||||
<div class="wa-chat">
|
||||
<div class="wa-message user">
|
||||
<div class="wa-bubble">
|
||||
<p>User message goes here</p>
|
||||
<div class="wa-time">10:30</div>
|
||||
</div>
|
||||
</div>
|
||||
<div class="wa-message bot">
|
||||
<div class="wa-bubble">
|
||||
<p>Bot response goes here</p>
|
||||
<div class="wa-time">10:30</div>
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
```
|
||||
|
||||
### Message Classes
|
||||
|
||||
| Class | Usage |
|
||||
|-------|-------|
|
||||
| `wa-chat` | Container for the conversation |
|
||||
| `wa-message` | Individual message wrapper |
|
||||
| `wa-message user` | User message (right-aligned, colored) |
|
||||
| `wa-message bot` | Bot message (left-aligned) |
|
||||
| `wa-bubble` | Message bubble with styling |
|
||||
| `wa-time` | Timestamp display |
|
||||
|
||||
### Formatting Guidelines
|
||||
|
||||
1. **User messages** — Use `wa-message user` class
|
||||
2. **Bot messages** — Use `wa-message bot` class
|
||||
3. **Timestamps** — Include `wa-time` div with realistic times
|
||||
4. **Multi-line responses** — Use separate `<p>` tags for each line
|
||||
5. **Status indicators** — Use text indicators (Success, Error, etc.) not emojis
|
||||
6. **Bold text** — Use `<strong>` for emphasis
|
||||
7. **Attachments** — Indicate with text like "[Attachment: filename.pdf]"
|
||||
|
||||
### Complete Example
|
||||
|
||||
```html
|
||||
<div class="wa-chat">
|
||||
<div class="wa-message bot">
|
||||
<div class="wa-bubble">
|
||||
<p>Hello! How can I help you today?</p>
|
||||
<div class="wa-time">10:30</div>
|
||||
</div>
|
||||
</div>
|
||||
<div class="wa-message user">
|
||||
<div class="wa-bubble">
|
||||
<p>I want to enroll in computer science</p>
|
||||
<div class="wa-time">10:31</div>
|
||||
</div>
|
||||
</div>
|
||||
<div class="wa-message bot">
|
||||
<div class="wa-bubble">
|
||||
<p>I'll help you enroll! What's your name?</p>
|
||||
<div class="wa-time">10:31</div>
|
||||
</div>
|
||||
</div>
|
||||
<div class="wa-message user">
|
||||
<div class="wa-bubble">
|
||||
<p>Sarah Chen</p>
|
||||
<div class="wa-time">10:31</div>
|
||||
</div>
|
||||
</div>
|
||||
<div class="wa-message bot">
|
||||
<div class="wa-bubble">
|
||||
<p><strong>Success:</strong> Welcome to Computer Science, Sarah!</p>
|
||||
<p>Your enrollment ID is: ENR-2025-0142</p>
|
||||
<div class="wa-time">10:31</div>
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
```
|
||||
|
||||
### When to Use Each Format
|
||||
|
||||
| Content Type | Format |
|
||||
|--------------|--------|
|
||||
| Interface screenshots | SVG wireframe |
|
||||
| System architecture | SVG diagram |
|
||||
| Data flow diagrams | SVG diagram |
|
||||
| Bot conversations | WhatsApp HTML |
|
||||
| API examples | Code blocks |
|
||||
| Configuration | Code blocks |
|
||||
|
||||
The WhatsApp chat styling is defined in `src/whatsapp-chat.css` and automatically included in the book build.
|
||||
|
|
|
|||
218
README.md
218
README.md
|
|
@ -1 +1,219 @@
|
|||
# General Bots
|
||||
|
||||

|
||||
|
||||
**Enterprise-Grade LLM Orchestrator & AI Automation Platform**
|
||||
|
||||
A strongly-typed, self-hosted conversational platform focused on convention over configuration and code-less approaches.
|
||||
|
||||
---
|
||||
|
||||
## 🏗️ Architecture
|
||||
|
||||
<img src="src/assets/platform-architecture.svg" alt="General Bots Platform Architecture" style="max-width: 100%; height: auto;">
|
||||
|
||||
---
|
||||
|
||||
## 📦 Repositories
|
||||
|
||||
| Repository | Description | Status |
|
||||
|------------|-------------|--------|
|
||||
| [**botserver**](https://github.com/GeneralBots/botserver) | Core API server - LLM orchestration, automation, integrations | ✅ Production |
|
||||
| [**botui**](https://github.com/GeneralBots/botui) | Pure web UI - HTMX-based interface (suite & minimal) | ✅ Production |
|
||||
| [**botapp**](https://github.com/GeneralBots/botapp) | Tauri desktop wrapper - native file access, system tray | ✅ Production |
|
||||
| [**botlib**](https://github.com/GeneralBots/botlib) | Shared Rust library - common types, HTTP client, utilities | ✅ Production |
|
||||
| [**bottemplates**](https://github.com/GeneralBots/bottemplates) | Templates - bots, apps, prompts, UI components | ✅ Production |
|
||||
| [**botbook**](https://github.com/GeneralBots/botbook) | Documentation - mdBook format, multi-language | ✅ Production |
|
||||
|
||||
---
|
||||
|
||||
## 🚀 Quick Start
|
||||
|
||||
### Prerequisites
|
||||
|
||||
- **Rust** (latest stable) - [Install from rustup.rs](https://rustup.rs/)
|
||||
- **Git** - [Download from git-scm.com](https://git-scm.com/downloads)
|
||||
|
||||
### Run the Server
|
||||
|
||||
```bash
|
||||
# Clone and run
|
||||
git clone https://github.com/GeneralBots/botserver
|
||||
cd botserver
|
||||
cargo run
|
||||
```
|
||||
|
||||
On first run, botserver automatically:
|
||||
- Installs required components (PostgreSQL, S3 storage, Cache, LLM)
|
||||
- Sets up database with migrations
|
||||
- Downloads AI models
|
||||
- Starts HTTP server at `http://127.0.0.1:8080`
|
||||
|
||||
### Run the Desktop App
|
||||
|
||||
```bash
|
||||
# Clone botui (pure web)
|
||||
git clone https://github.com/GeneralBots/botui
|
||||
cd botui
|
||||
cargo run # Starts web server at :3000
|
||||
|
||||
# In another terminal, clone and run botapp (Tauri desktop)
|
||||
git clone https://github.com/GeneralBots/botapp
|
||||
cd botapp
|
||||
cargo tauri dev
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## ✨ Key Features
|
||||
|
||||
### 🤖 Multi-Vendor LLM API
|
||||
Unified interface for OpenAI, Groq, Claude, Anthropic, and local models.
|
||||
|
||||
### 🔧 MCP + LLM Tools Generation
|
||||
Instant tool creation from code and functions - no complex configurations.
|
||||
|
||||
### 💾 Semantic Caching
|
||||
Intelligent response caching achieving **70% cost reduction** on LLM calls.
|
||||
|
||||
### 🌐 Web Automation Engine
|
||||
Browser automation combined with AI intelligence for complex workflows.
|
||||
|
||||
### 📊 Enterprise Data Connectors
|
||||
Native integrations with CRM, ERP, databases, and external services.
|
||||
|
||||
### 🔄 Git-like Version Control
|
||||
Full history with rollback capabilities for all configurations and data.
|
||||
|
||||
---
|
||||
|
||||
## 🎯 4 Essential Keywords
|
||||
|
||||
General Bots provides a minimal, focused system:
|
||||
|
||||
```basic
|
||||
USE KB "knowledge-base" ' Load knowledge base into vector database
|
||||
CLEAR KB "knowledge-base" ' Remove KB from session
|
||||
USE TOOL "tool-name" ' Make tool available to LLM
|
||||
CLEAR TOOLS ' Remove all tools from session
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 🏛️ Architecture Details
|
||||
|
||||
### botserver (Core)
|
||||
The main API server handling:
|
||||
- LLM orchestration and prompt management
|
||||
- Multi-channel communication (WhatsApp, Teams, Email, Web)
|
||||
- File storage and drive management
|
||||
- Task scheduling and automation
|
||||
- Authentication and authorization
|
||||
|
||||
### botui (Web Interface)
|
||||
Pure web UI with zero native dependencies:
|
||||
- **Suite**: Full-featured multi-app interface
|
||||
- **Minimal**: Lightweight single-page chat
|
||||
- HTMX-powered for minimal JavaScript
|
||||
- Works in any browser
|
||||
|
||||
### botapp (Desktop)
|
||||
Tauri wrapper adding native capabilities:
|
||||
- Local file system access
|
||||
- System tray integration
|
||||
- Native dialogs and notifications
|
||||
- Desktop-specific features
|
||||
|
||||
### botlib (Shared Library)
|
||||
Common Rust code shared across projects:
|
||||
- HTTP client for botserver communication
|
||||
- Shared types and models
|
||||
- Branding and configuration utilities
|
||||
- Error handling
|
||||
|
||||
---
|
||||
|
||||
## 🔧 Development Setup
|
||||
|
||||
```bash
|
||||
# Clone all repositories
|
||||
git clone https://github.com/GeneralBots/botserver botserver
|
||||
git clone https://github.com/GeneralBots/botui
|
||||
git clone https://github.com/GeneralBots/botapp
|
||||
git clone https://github.com/GeneralBots/botlib
|
||||
git clone https://github.com/GeneralBots/botbook botbook
|
||||
|
||||
# Build all (from each directory)
|
||||
cd botlib && cargo build
|
||||
cd ../botserver && cargo build
|
||||
cd ../botui && cargo build
|
||||
cd ../botapp && cargo build
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 📖 Documentation
|
||||
|
||||
- **[Complete Documentation](https://github.com/GeneralBots/botbook)** - Full mdBook documentation
|
||||
- **[Quick Start Guide](https://github.com/GeneralBots/botserver/blob/main/docs/QUICK_START.md)** - Get started in minutes
|
||||
- **[API Reference](https://github.com/GeneralBots/botserver/blob/main/docs/src/chapter-10-api/README.md)** - REST API documentation
|
||||
- **[Architecture Guide](https://github.com/GeneralBots/botserver/blob/main/docs/src/chapter-07-gbapp/README.md)** - System architecture
|
||||
|
||||
---
|
||||
|
||||
## 🆚 Why General Bots?
|
||||
|
||||
| vs. Alternative | General Bots Advantage |
|
||||
|-----------------|----------------------|
|
||||
| **ChatGPT/Claude** | Automates entire business processes, not just chat |
|
||||
| **n8n/Make** | Simpler approach with minimal programming |
|
||||
| **Microsoft 365** | User control, not locked ecosystems |
|
||||
| **Salesforce** | Open-source AI orchestration connecting all systems |
|
||||
|
||||
---
|
||||
|
||||
## 🛡️ Security
|
||||
|
||||
- **AGPL-3.0 License** - True open source with contribution requirements
|
||||
- **Self-hosted** - Your data stays on your infrastructure
|
||||
- **Enterprise-grade** - 5+ years of stability
|
||||
- **No vendor lock-in** - Open protocols and standards
|
||||
|
||||
Report security issues to: **security@pragmatismo.com.br**
|
||||
|
||||
---
|
||||
|
||||
## 🤝 Contributing
|
||||
|
||||
We welcome contributions! See our [Contributing Guidelines](https://github.com/GeneralBots/botserver/blob/main/docs/src/chapter-13-community/README.md).
|
||||
|
||||
### Contributors
|
||||
|
||||
<a href="https://github.com/generalbots/botserver/graphs/contributors">
|
||||
<img src="https://contrib.rocks/image?repo=generalbots/botserver" />
|
||||
</a>
|
||||
|
||||
---
|
||||
|
||||
## 📄 License
|
||||
|
||||
General Bots is licensed under **AGPL-3.0**.
|
||||
|
||||
According to our dual licensing model, this program can be used either under the terms of the GNU Affero General Public License, version 3, or under a proprietary license.
|
||||
|
||||
Copyright (c) pragmatismo.com.br. All rights reserved.
|
||||
|
||||
---
|
||||
|
||||
## 🔗 Links
|
||||
|
||||
- **Website:** [pragmatismo.com.br](https://pragmatismo.com.br)
|
||||
- **Documentation:** [docs.pragmatismo.com.br](https://docs.pragmatismo.com.br)
|
||||
- **Stack Overflow:** Tag questions with `generalbots`
|
||||
- **Video Tutorial:** [7 AI General Bots LLM Templates](https://www.youtube.com/watch?v=KJgvUPXi3Fw)
|
||||
|
||||
---
|
||||
|
||||
> **Code Name:** [Guaribas](https://en.wikipedia.org/wiki/Guaribas) (a city in Brazil, state of Piauí)
|
||||
>
|
||||
> *"No one should have to do work that can be done by a machine."* - Roberto Mangabeira Unger
|
||||
|
|
@ -1,6 +1,6 @@
|
|||
# First Conversation
|
||||
|
||||
After BotServer starts, you can immediately start chatting with your bot. No programming required!
|
||||
After botserver starts, you can immediately start chatting with your bot. No programming required!
|
||||
|
||||
## Just Start Talking
|
||||
|
||||
|
|
@ -103,7 +103,7 @@ Documents in `.gbkb/` combined with tools in `.bas` files and the LLM create an
|
|||
|
||||
## Creating Your First Bot
|
||||
|
||||
Start by creating the directory structure for your bot with folders for dialog scripts, knowledge base documents, and bot configuration. Add your documents to the `.gbkb/` directory including PDFs, Word documents, text files, and Markdown files. Optionally create tools as `.bas` files to handle specific actions like processing forms or calling APIs. Then restart BotServer and start chatting. The LLM will answer questions from your documents, call your tools when appropriate, and handle the entire conversation naturally.
|
||||
Start by creating the directory structure for your bot with folders for dialog scripts, knowledge base documents, and bot configuration. Add your documents to the `.gbkb/` directory including PDFs, Word documents, text files, and Markdown files. Optionally create tools as `.bas` files to handle specific actions like processing forms or calling APIs. Then restart botserver and start chatting. The LLM will answer questions from your documents, call your tools when appropriate, and handle the entire conversation naturally.
|
||||
|
||||
```bash
|
||||
mkdir -p mybot.gbai/mybot.gbdialog
|
||||
|
|
@ -125,7 +125,7 @@ TALK "Done! " + result
|
|||
|
||||
## No Programming Required
|
||||
|
||||
Traditional chatbots require complex logic with IF/THEN statements, intent detection, and multi-step dialog management. With BotServer, you simply create the tool with parameters and a description, and the LLM handles all the conversation logic automatically.
|
||||
Traditional chatbots require complex logic with IF/THEN statements, intent detection, and multi-step dialog management. With botserver, you simply create the tool with parameters and a description, and the LLM handles all the conversation logic automatically.
|
||||
|
||||
Traditional approach (don't do this):
|
||||
|
||||
|
|
@ -140,7 +140,7 @@ IF intent = "enrollment" THEN
|
|||
ENDIF
|
||||
```
|
||||
|
||||
BotServer approach (just create the tool):
|
||||
botserver approach (just create the tool):
|
||||
|
||||
```basic
|
||||
' In enrollment.bas - becomes a tool automatically
|
||||
|
|
|
|||
|
|
@ -1,6 +1,6 @@
|
|||
# Installation
|
||||
|
||||
BotServer installs itself automatically through the bootstrap process. Just run the binary.
|
||||
botserver installs itself automatically through the bootstrap process. Just run the binary.
|
||||
|
||||
## System Requirements
|
||||
|
||||
|
|
|
|||
|
|
@ -1,16 +1,16 @@
|
|||
# Configuring Local Development Access
|
||||
|
||||
After bootstrap, BotServer services are immediately accessible via **IP addresses** - no configuration required. For those who prefer friendly hostnames, optional DNS setup is also available.
|
||||
After bootstrap, botserver services are immediately accessible via **IP addresses** - no configuration required. For those who prefer friendly hostnames, optional DNS setup is also available.
|
||||
|
||||
## Zero Configuration: IP Access (Default)
|
||||
|
||||
BotServer certificates include `127.0.0.1` as a Subject Alternative Name (SAN), so **mTLS works immediately** via IP address without any system changes.
|
||||
botserver certificates include `127.0.0.1` as a Subject Alternative Name (SAN), so **mTLS works immediately** via IP address without any system changes.
|
||||
|
||||
### Service Ports
|
||||
|
||||
| Component | Description | IP:Port |
|
||||
|-----------|-------------|---------|
|
||||
| api | Main BotServer API | `127.0.0.1:8443` (HTTPS) / `127.0.0.1:8080` (HTTP) |
|
||||
| api | Main botserver API | `127.0.0.1:8443` (HTTPS) / `127.0.0.1:8080` (HTTP) |
|
||||
| tables | PostgreSQL database | `127.0.0.1:5432` |
|
||||
| drive | Object storage (S3-compatible) | `127.0.0.1:9000` |
|
||||
| cache | Redis cache | `127.0.0.1:6379` |
|
||||
|
|
@ -101,7 +101,7 @@ async fn main() -> Result<(), Box<dyn std::error::Error>> {
|
|||
|
||||
### Remote Server Access
|
||||
|
||||
If BotServer runs on a different machine (e.g., `192.168.1.100`), regenerate certificates with additional IP SANs:
|
||||
If botserver runs on a different machine (e.g., `192.168.1.100`), regenerate certificates with additional IP SANs:
|
||||
|
||||
```bash
|
||||
./botserver regenerate-certs --san-ip 192.168.1.100 --san-ip 10.0.0.50
|
||||
|
|
@ -218,9 +218,9 @@ sudo dscacheutil -flushcache
|
|||
sudo killall -HUP mDNSResponder
|
||||
```
|
||||
|
||||
### Option 2: Use BotServer's CoreDNS
|
||||
### Option 2: Use botserver's CoreDNS
|
||||
|
||||
BotServer runs CoreDNS on port 53. Point your system to use it as DNS server.
|
||||
botserver runs CoreDNS on port 53. Point your system to use it as DNS server.
|
||||
|
||||
#### Windows
|
||||
|
||||
|
|
@ -254,7 +254,7 @@ nameserver 127.0.0.1
|
|||
EOF
|
||||
```
|
||||
|
||||
This routes only `*.botserver.local` queries to BotServer's DNS.
|
||||
This routes only `*.botserver.local` queries to botserver's DNS.
|
||||
|
||||
---
|
||||
|
||||
|
|
|
|||
|
|
@ -1,16 +1,16 @@
|
|||
# Overview
|
||||
|
||||
BotServer is an open-source conversational AI platform built in Rust that enables developers to create, deploy, and manage intelligent bots with minimal configuration. This chapter provides a comprehensive introduction to the platform's architecture, capabilities, and design philosophy.
|
||||
botserver is an open-source conversational AI platform built in Rust that enables developers to create, deploy, and manage intelligent bots with minimal configuration. This chapter provides a comprehensive introduction to the platform's architecture, capabilities, and design philosophy.
|
||||
|
||||
|
||||
## Core Philosophy
|
||||
|
||||
BotServer was designed around five guiding principles that shape every aspect of the platform. Zero Configuration means the system works out of the box with sensible defaults, eliminating lengthy setup processes. The Package-Based approach ensures bots are self-contained in `.gbai` folders that can be copied and deployed anywhere. BASIC Scripting provides simple, accessible programming for conversation flows that non-programmers can understand and modify. Multi-Channel support means you deploy once and run everywhere across Web, WhatsApp, Teams, and other platforms. Knowledge-First design provides built-in document management and semantic search as core capabilities rather than afterthoughts.
|
||||
botserver was designed around five guiding principles that shape every aspect of the platform. Zero Configuration means the system works out of the box with sensible defaults, eliminating lengthy setup processes. The Package-Based approach ensures bots are self-contained in `.gbai` folders that can be copied and deployed anywhere. BASIC Scripting provides simple, accessible programming for conversation flows that non-programmers can understand and modify. Multi-Channel support means you deploy once and run everywhere across Web, WhatsApp, Teams, and other platforms. Knowledge-First design provides built-in document management and semantic search as core capabilities rather than afterthoughts.
|
||||
|
||||
|
||||
## Architecture Overview
|
||||
|
||||
BotServer uses a modular architecture organized into three distinct layers that work together to provide a complete conversational AI platform.
|
||||
botserver uses a modular architecture organized into three distinct layers that work together to provide a complete conversational AI platform.
|
||||
|
||||
### Storage Layer
|
||||
|
||||
|
|
@ -29,7 +29,7 @@ The service layer provides the infrastructure that supports bot operations. The
|
|||
|
||||
### Conversation Management
|
||||
|
||||
BotServer provides comprehensive conversation management capabilities. Sessions persist across interactions, maintaining context and state throughout multi-turn dialogs. The context management system tracks conversation history and user information across interactions. Parallel conversation handling allows a single bot instance to manage thousands of simultaneous conversations efficiently.
|
||||
botserver provides comprehensive conversation management capabilities. Sessions persist across interactions, maintaining context and state throughout multi-turn dialogs. The context management system tracks conversation history and user information across interactions. Parallel conversation handling allows a single bot instance to manage thousands of simultaneous conversations efficiently.
|
||||
|
||||
### Knowledge Base System
|
||||
|
||||
|
|
@ -45,14 +45,14 @@ Deploy your bot once and reach users across multiple channels. The web chat inte
|
|||
|
||||
### Enterprise Features
|
||||
|
||||
BotServer includes capabilities required for enterprise deployments. Multi-tenancy support allows a single installation to serve multiple organizations with complete isolation. Role-based access control restricts actions based on user roles and permissions. Comprehensive audit logging tracks all actions for compliance and debugging. Horizontal scaling distributes load across multiple instances. High availability configurations ensure continuous operation even during failures.
|
||||
botserver includes capabilities required for enterprise deployments. Multi-tenancy support allows a single installation to serve multiple organizations with complete isolation. Role-based access control restricts actions based on user roles and permissions. Comprehensive audit logging tracks all actions for compliance and debugging. Horizontal scaling distributes load across multiple instances. High availability configurations ensure continuous operation even during failures.
|
||||
|
||||
|
||||
## System Requirements
|
||||
|
||||
### Minimum Requirements
|
||||
|
||||
For development and testing purposes, BotServer runs comfortably on modest hardware. You need at least 4GB of RAM to run all components. A single CPU core is sufficient for light workloads. Reserve at least 10GB of disk space for the application, databases, and documents. The platform runs on Linux, macOS, or Windows operating systems.
|
||||
For development and testing purposes, botserver runs comfortably on modest hardware. You need at least 4GB of RAM to run all components. A single CPU core is sufficient for light workloads. Reserve at least 10GB of disk space for the application, databases, and documents. The platform runs on Linux, macOS, or Windows operating systems.
|
||||
|
||||
### Recommended for Production
|
||||
|
||||
|
|
@ -88,7 +88,7 @@ The `.gbot` subfolder contains configuration files including the main `config.cs
|
|||
|
||||
### Standalone Server
|
||||
|
||||
The standalone deployment model runs a single BotServer instance serving multiple bots. This approach provides the simplest setup with shared resources across bots. Standalone deployment works best for small to medium deployments where isolation between bots is not critical.
|
||||
The standalone deployment model runs a single botserver instance serving multiple bots. This approach provides the simplest setup with shared resources across bots. Standalone deployment works best for small to medium deployments where isolation between bots is not critical.
|
||||
|
||||
### LXC Containers
|
||||
|
||||
|
|
@ -96,12 +96,12 @@ Linux containers provide lightweight virtualization for bot isolation. Each bot
|
|||
|
||||
### Embedded Mode
|
||||
|
||||
Embedded deployment integrates BotServer into existing applications as a library. This mode provides programmatic control over bot behavior and direct integration with application logic. Custom integrations can use the embedded mode to add conversational capabilities to any Rust application.
|
||||
Embedded deployment integrates botserver into existing applications as a library. This mode provides programmatic control over bot behavior and direct integration with application logic. Custom integrations can use the embedded mode to add conversational capabilities to any Rust application.
|
||||
|
||||
|
||||
## Getting Started
|
||||
|
||||
Installation begins by downloading and running the BotServer binary. The bootstrap process automatically downloads all required components to the `botserver-stack/` directory, including database binaries, the object storage server, cache server, LLM runtime, and other dependencies.
|
||||
Installation begins by downloading and running the botserver binary. The bootstrap process automatically downloads all required components to the `botserver-stack/` directory, including database binaries, the object storage server, cache server, LLM runtime, and other dependencies.
|
||||
|
||||
Bot deployment uses object storage buckets. Each bot receives its own bucket for file storage. Bots are deployed to the drive rather than the work folder, which is reserved for internal operations as documented in the gbapp chapter.
|
||||
|
||||
|
|
@ -129,7 +129,7 @@ Healthcare bots assist with patient engagement while maintaining compliance. App
|
|||
|
||||
## Security Features
|
||||
|
||||
BotServer implements comprehensive security at every layer. Authentication integrates with directory services for centralized user management. SSL/TLS encryption protects all network communications. Session tokens use cryptographically secure generation and validation. Input sanitization prevents injection attacks across all user inputs. SQL injection prevention uses parameterized queries throughout. XSS protection sanitizes output displayed to users. Rate limiting prevents abuse and denial of service attacks. Audit logging records all significant actions for compliance and forensics.
|
||||
botserver implements comprehensive security at every layer. Authentication integrates with directory services for centralized user management. SSL/TLS encryption protects all network communications. Session tokens use cryptographically secure generation and validation. Input sanitization prevents injection attacks across all user inputs. SQL injection prevention uses parameterized queries throughout. XSS protection sanitizes output displayed to users. Rate limiting prevents abuse and denial of service attacks. Audit logging records all significant actions for compliance and forensics.
|
||||
|
||||
|
||||
## Monitoring and Operations
|
||||
|
|
@ -175,4 +175,4 @@ General Bots is open source under the AGPL (GNU Affero General Public License).
|
|||
|
||||
## Summary
|
||||
|
||||
BotServer provides a complete platform for building conversational AI applications. The combination of simple BASIC scripting, automatic setup, and enterprise features bridges the gap between simple chatbots and complex AI systems. The focus on packages, minimal configuration, and multi-channel support makes BotServer suitable for both rapid prototyping and production deployments serving millions of users.
|
||||
botserver provides a complete platform for building conversational AI applications. The combination of simple BASIC scripting, automatic setup, and enterprise features bridges the gap between simple chatbots and complex AI systems. The focus on packages, minimal configuration, and multi-channel support makes botserver suitable for both rapid prototyping and production deployments serving millions of users.
|
||||
|
|
@ -2,7 +2,7 @@
|
|||
|
||||
## Installation in 3 Steps
|
||||
|
||||
### 1. Run BotServer
|
||||
### 1. Run botserver
|
||||
|
||||
```bash
|
||||
./botserver
|
||||
|
|
@ -15,7 +15,7 @@ That's it! No configuration needed.
|
|||
You'll see:
|
||||
|
||||
```
|
||||
BotServer starting...
|
||||
botserver starting...
|
||||
Bootstrap: Detecting system...
|
||||
Installing PostgreSQL...
|
||||
Database created
|
||||
|
|
@ -28,7 +28,7 @@ Installing Cache...
|
|||
Creating bots from templates...
|
||||
default.gbai deployed
|
||||
announcements.gbai deployed
|
||||
BotServer ready at http://localhost:8080
|
||||
botserver ready at http://localhost:8080
|
||||
```
|
||||
|
||||
### 3. Open Browser
|
||||
|
|
@ -117,7 +117,7 @@ The bot automatically:
|
|||
|
||||
## Container Deployment (LXC)
|
||||
|
||||
For production isolation, BotServer supports **LXC** (Linux Containers):
|
||||
For production isolation, botserver supports **LXC** (Linux Containers):
|
||||
|
||||
```bash
|
||||
# Create container
|
||||
|
|
@ -127,7 +127,7 @@ lxc-create -n botserver -t download -- -d ubuntu -r jammy -a amd64
|
|||
lxc-start -n botserver
|
||||
lxc-attach -n botserver
|
||||
|
||||
# Install BotServer inside container
|
||||
# Install botserver inside container
|
||||
./botserver
|
||||
```
|
||||
|
||||
|
|
|
|||
|
|
@ -1,6 +1,6 @@
|
|||
# Sessions and Channels
|
||||
|
||||
Every conversation has memory. Sessions are the beating heart of BotServer because they remember who you are, what you have said, and where you left off. Even if you close your browser and come back tomorrow, your conversation continues right where it paused.
|
||||
Every conversation has memory. Sessions are the beating heart of botserver because they remember who you are, what you have said, and where you left off. Even if you close your browser and come back tomorrow, your conversation continues right where it paused.
|
||||
|
||||
<img src="../assets/chapter-01/session-manager.svg" alt="Session Manager" style="max-height: 400px; width: 100%; object-fit: contain;">
|
||||
|
||||
|
|
@ -216,4 +216,4 @@ TALK "I understand you need help with: " + answer
|
|||
|
||||
## Summary
|
||||
|
||||
Sessions and channels work together seamlessly in BotServer. Sessions handle state management automatically across any channel, persist data reliably through cache and database layers, and scale efficiently to thousands of concurrent conversations. You focus on writing the conversation flow while the system handles memory management and multi-channel delivery transparently.
|
||||
Sessions and channels work together seamlessly in botserver. Sessions handle state management automatically across any channel, persist data reliably through cache and database layers, and scale efficiently to thousands of concurrent conversations. You focus on writing the conversation flow while the system handles memory management and multi-channel delivery transparently.
|
||||
|
|
@ -1,6 +1,6 @@
|
|||
# .gbai Architecture
|
||||
|
||||
**A bot is just a folder.** The `.gbai` extension marks a directory as a BotServer package containing everything needed to run a conversational AI bot - scripts, documents, configuration, and themes.
|
||||
**A bot is just a folder.** The `.gbai` extension marks a directory as a botserver package containing everything needed to run a conversational AI bot - scripts, documents, configuration, and themes.
|
||||
|
||||
## The Dead Simple Structure
|
||||
|
||||
|
|
@ -21,7 +21,7 @@ That's it. No manifests, no build files, no dependencies. Copy the folder to dep
|
|||
|
||||
## How Bootstrap Finds Bots
|
||||
|
||||
At startup, BotServer scans `templates/` for any folder ending in `.gbai`:
|
||||
At startup, botserver scans `templates/` for any folder ending in `.gbai`:
|
||||
|
||||
```
|
||||
templates/
|
||||
|
|
@ -177,7 +177,7 @@ No build step. No compilation. Just copy files.
|
|||
|
||||
## Multi-Bot Hosting
|
||||
|
||||
One BotServer runs multiple bots:
|
||||
One botserver runs multiple bots:
|
||||
|
||||
```
|
||||
templates/
|
||||
|
|
@ -209,7 +209,7 @@ Each bot:
|
|||
|
||||
## Bootstrap Process
|
||||
|
||||
When BotServer starts:
|
||||
When botserver starts:
|
||||
|
||||
<img src="../assets/chapter-02/template-deployment-flow.svg" alt="Template Deployment Flow" style="max-height: 400px; width: 100%; object-fit: contain;">
|
||||
|
||||
|
|
@ -277,6 +277,6 @@ user-file-limit,52428800
|
|||
|
||||
## Summary
|
||||
|
||||
The `.gbai` architecture keeps bot development simple. No complex frameworks, no build systems, no deployment pipelines. Just organize your files in folders, and BotServer handles the rest. Focus on content and conversation, not configuration.
|
||||
The `.gbai` architecture keeps bot development simple. No complex frameworks, no build systems, no deployment pipelines. Just organize your files in folders, and botserver handles the rest. Focus on content and conversation, not configuration.
|
||||
|
||||
Next: Learn about [.gbdialog Dialogs](./gbdialog.md) for writing conversation scripts.
|
||||
|
|
@ -1,6 +1,6 @@
|
|||
# Bot Templates
|
||||
|
||||
BotServer includes pre-built bot templates for various use cases. Each template is a complete `.gbai` package ready to deploy.
|
||||
botserver includes pre-built bot templates for various use cases. Each template is a complete `.gbai` package ready to deploy.
|
||||
|
||||
---
|
||||
|
||||
|
|
|
|||
|
|
@ -1,6 +1,6 @@
|
|||
# Caching
|
||||
|
||||
BotServer includes automatic caching to improve response times and reduce redundant processing, including semantic caching for LLM responses using an in-memory cache component.
|
||||
botserver includes automatic caching to improve response times and reduce redundant processing, including semantic caching for LLM responses using an in-memory cache component.
|
||||
|
||||
<img src="../assets/chapter-03/caching-architecture.svg" alt="Caching Architecture" style="max-height: 400px; width: 100%; object-fit: contain;">
|
||||
|
||||
|
|
@ -10,7 +10,7 @@ The caching system provides exact match caching for identical prompts and semant
|
|||
|
||||
## How Caching Works
|
||||
|
||||
Caching in BotServer is controlled by configuration parameters in `config.csv`. The system automatically caches LLM responses and manages conversation history.
|
||||
Caching in botserver is controlled by configuration parameters in `config.csv`. The system automatically caches LLM responses and manages conversation history.
|
||||
|
||||
When enabled, the semantic cache operates through a straightforward process. When a user asks a question, the system checks if a semantically similar question was asked before. If the similarity exceeds the threshold (typically 0.95), it returns the cached response. Otherwise, it generates a new response and caches it for future queries.
|
||||
|
||||
|
|
@ -143,4 +143,4 @@ Cache is managed automatically through TTL expiration and eviction policies. To
|
|||
|
||||
## Summary
|
||||
|
||||
The semantic caching system in BotServer provides intelligent response caching that reduces response latency by 10-100x and cuts API costs by 90% or more. Response quality is maintained through semantic matching that understands query intent rather than requiring exact matches. The system scales automatically with the cache component to handle increasing load. Configure caching based on your bot's needs, monitor performance metrics, and tune parameters for optimal results.
|
||||
The semantic caching system in botserver provides intelligent response caching that reduces response latency by 10-100x and cuts API costs by 90% or more. Response quality is maintained through semantic matching that understands query intent rather than requiring exact matches. The system scales automatically with the cache component to handle increasing load. Configure caching based on your bot's needs, monitor performance metrics, and tune parameters for optimal results.
|
||||
|
|
@ -1,6 +1,6 @@
|
|||
# Chapter 03 – Knowledge Base System Overview
|
||||
|
||||
This chapter explains how BotServer manages knowledge base collections, indexing, caching, semantic search, and conversation memory. The implementation uses vector databases for semantic search and intelligent memory management for context optimization.
|
||||
This chapter explains how botserver manages knowledge base collections, indexing, caching, semantic search, and conversation memory. The implementation uses vector databases for semantic search and intelligent memory management for context optimization.
|
||||
|
||||
| Document | File | Description |
|
||||
|----------|------|-------------|
|
||||
|
|
|
|||
|
|
@ -1,6 +1,6 @@
|
|||
# Vector Collections
|
||||
|
||||
This chapter explains how BotServer organizes knowledge into vector collections, the searchable units that power semantic retrieval. Understanding how collections work helps you structure documents effectively and optimize the knowledge your bots can access.
|
||||
This chapter explains how botserver organizes knowledge into vector collections, the searchable units that power semantic retrieval. Understanding how collections work helps you structure documents effectively and optimize the knowledge your bots can access.
|
||||
|
||||
<img src="../assets/chapter-03/storage-breakdown.svg" alt="Storage Breakdown" style="max-height: 400px; width: 100%; object-fit: contain;">
|
||||
|
||||
|
|
@ -8,7 +8,7 @@ This chapter explains how BotServer organizes knowledge into vector collections,
|
|||
|
||||
Vector collections emerge automatically from the folder structure within your .gbkb directory. Each folder you create becomes a distinct collection, indexed separately and activated independently. This direct mapping between physical organization and logical collections makes knowledge management intuitive—organize files into folders by topic, and those folders become the collections you reference in your scripts.
|
||||
|
||||
When BotServer encounters a .gbkb folder, it scans for documents in supported formats including PDF, DOCX, TXT, HTML, and Markdown. Each file's content is extracted, split into manageable chunks, converted to vector embeddings, and stored in the vector database. The folder name becomes the collection identifier you use with the USE KB keyword.
|
||||
When botserver encounters a .gbkb folder, it scans for documents in supported formats including PDF, DOCX, TXT, HTML, and Markdown. Each file's content is extracted, split into manageable chunks, converted to vector embeddings, and stored in the vector database. The folder name becomes the collection identifier you use with the USE KB keyword.
|
||||
|
||||
This automatic process means no manual indexing configuration is required. Add files to a folder, and they become searchable. Remove files, and they disappear from search results. The system tracks file changes through hash comparisons, triggering reindexing only when content actually changes.
|
||||
|
||||
|
|
@ -20,7 +20,7 @@ For each file requiring processing, text extraction pulls readable content from
|
|||
|
||||
The chunking phase splits long documents into smaller pieces suitable for embedding and retrieval. Each chunk contains approximately 500 tokens with overlap between adjacent chunks to preserve context across boundaries. This sizing balances granularity—enabling precise matches—against coherence—keeping related information together.
|
||||
|
||||
Embedding generation converts each text chunk into a numerical vector representation. BotServer uses the BGE embedding model by default, producing 384-dimensional vectors that capture semantic meaning. These embeddings enable the similarity comparisons that power semantic search.
|
||||
Embedding generation converts each text chunk into a numerical vector representation. botserver uses the BGE embedding model by default, producing 384-dimensional vectors that capture semantic meaning. These embeddings enable the similarity comparisons that power semantic search.
|
||||
|
||||
Finally, the vectors and their associated metadata are stored in the vector database, organized by collection. Each entry includes the embedding vector, the original text chunk, the source file path, and position information enabling reconstruction of context.
|
||||
|
||||
|
|
@ -54,7 +54,7 @@ This entire process happens transparently. Developers don't write search queries
|
|||
|
||||
## Embedding Configuration
|
||||
|
||||
The embedding model determines how meaning is captured in vectors and significantly influences search quality. BotServer uses a locally-running BGE model by default, configured through the embedding URL and model path settings in config.csv.
|
||||
The embedding model determines how meaning is captured in vectors and significantly influences search quality. botserver uses a locally-running BGE model by default, configured through the embedding URL and model path settings in config.csv.
|
||||
|
||||
The default model provides good general-purpose performance for English content. Organizations with specialized vocabulary or multilingual requirements might benefit from alternative models. The embedding infrastructure supports any compatible model, allowing customization for specific domains.
|
||||
|
||||
|
|
|
|||
|
|
@ -31,7 +31,7 @@ http://localhost:8080/console → Terminal mode
|
|||
|-----|---------|
|
||||
| Chat | AI assistant conversations |
|
||||
| Drive | File management |
|
||||
| Tasks | To-do lists |
|
||||
| Tasks | LLM-powered intelligent execution |
|
||||
| Mail | Email client |
|
||||
| Calendar | Scheduling |
|
||||
| Meet | Video calls |
|
||||
|
|
|
|||
|
|
@ -12,7 +12,7 @@ Click any app icon in the top-right menu (⋮⋮⋮) to open it.
|
|||
|-----|--------------|
|
||||
| 💬 **Chat** | Talk to your AI assistant |
|
||||
| 📁 **Drive** | Store and organize your files |
|
||||
| ✓ **Tasks** | Keep track of your to-do list |
|
||||
| ⚡ **Tasks** | LLM-powered intelligent task execution |
|
||||
| ✉ **Mail** | Send and receive emails |
|
||||
| 📅 **Calendar** | Schedule meetings and events |
|
||||
| 🎥 **Meet** | Video calls with your team |
|
||||
|
|
@ -59,7 +59,7 @@ Learn more about each app:
|
|||
|
||||
- [Chat](./chat.md) - Talk to your AI assistant
|
||||
- [Drive](./drive.md) - Manage your files
|
||||
- [Tasks](./tasks.md) - Track your to-dos
|
||||
- [Tasks](./tasks.md) - LLM-powered intelligent execution
|
||||
- [Mail](./mail.md) - Handle your email
|
||||
- [Calendar](./calendar.md) - Manage your schedule
|
||||
- [Meet](./meet.md) - Join video calls
|
||||
|
|
|
|||
|
|
@ -1,182 +1,376 @@
|
|||
# Sources - Prompts & Templates
|
||||
# Sources
|
||||
|
||||
> **Your bot configuration hub**
|
||||
|
||||
<img src="../../assets/suite/sources-screen.svg" alt="Sources Interface Screen" style="max-width: 100%; height: auto;">
|
||||
> **Repositories, Apps, Prompts, Templates & MCP Servers**
|
||||
|
||||
---
|
||||
|
||||
<img src="../../assets/chapter-04/sources-interface.svg" alt="Sources Interface" style="max-width: 100%; height: auto;">
|
||||
|
||||
## Overview
|
||||
|
||||
Sources is the configuration center in General Bots Suite. Manage your bots, prompts, templates, and knowledge bases all in one place. Sources is where you create new bots, customize their behavior, and organize the content that powers your AI assistant.
|
||||
Sources is where you connect everything your bot can reference. Add Git repositories, manage generated apps, configure prompts, and connect MCP servers. Most importantly, Sources enables **@mentions** in chat—reference `@botserver` to work on a repository or `@myapp` to modify an app you created.
|
||||
|
||||
---
|
||||
|
||||
## Features
|
||||
## Tabs
|
||||
|
||||
### Managing Bots
|
||||
| Tab | What It Contains |
|
||||
|-----|------------------|
|
||||
| **Repositories** | Git repos (GitHub, GitLab, Bitbucket) |
|
||||
| **Apps** | HTMX apps created with CREATE SITE |
|
||||
| **Prompts** | System prompts and templates |
|
||||
| **Templates** | Bot packages (.gbai) |
|
||||
| **News** | Platform updates and announcements |
|
||||
| **MCP Servers** | Model Context Protocol servers |
|
||||
| **LLM Tools** | Available LLM-invokable tools |
|
||||
| **Models** | Configured AI models |
|
||||
|
||||
#### Creating a New Bot
|
||||
---
|
||||
|
||||
1. Click **+ New Bot** in the top right
|
||||
2. Fill in the bot details:
|
||||
## Repositories
|
||||
|
||||
Connect Git repositories so Tasks can read, modify, and commit code.
|
||||
|
||||
### Adding a Repository
|
||||
|
||||
1. Click **+ Add Repository**
|
||||
2. Enter the repository URL (HTTPS or SSH)
|
||||
3. Authenticate if private
|
||||
4. Click **Connect**
|
||||
|
||||
### Repository Card
|
||||
|
||||
Each connected repository shows:
|
||||
|
||||
| Field | Description |
|
||||
|-------|-------------|
|
||||
| **Bot ID** | Unique identifier (lowercase, numbers, hyphens only) |
|
||||
| **Display Name** | User-friendly name shown in chat |
|
||||
| **Description** | Brief explanation of what the bot does |
|
||||
| **Start from** | Blank, Template, or Clone existing |
|
||||
| **Name** | Repository name with @mention tag |
|
||||
| **Owner** | Organization or user |
|
||||
| **Description** | From repository README |
|
||||
| **Language** | Primary programming language |
|
||||
| **Stars/Forks** | GitHub metrics |
|
||||
| **Status** | Connected or disconnected |
|
||||
|
||||
#### Bot Settings
|
||||
### Using @mentions with Repositories
|
||||
|
||||
Click the **⚙️** icon on any bot to configure:
|
||||
In chat, type `@` followed by the repo name:
|
||||
|
||||
**General Settings:**
|
||||
```
|
||||
You: @botserver add error handling to the login function
|
||||
|
||||
| Setting | Description |
|
||||
|---------|-------------|
|
||||
| **Display Name** | Name shown to users |
|
||||
| **Welcome Message** | First message when conversation starts |
|
||||
| **Language** | Primary language for the bot |
|
||||
| **Timezone** | Bot's timezone for date/time operations |
|
||||
| **Status** | Live, Draft, or Maintenance |
|
||||
|
||||
**Status Options:**
|
||||
- **Live** - Bot is active and responding
|
||||
- **Draft** - Bot is hidden from users
|
||||
- **Maintenance** - Shows maintenance message
|
||||
|
||||
#### AI Settings
|
||||
|
||||
| Setting | Description |
|
||||
|---------|-------------|
|
||||
| **Provider** | AI provider (OpenAI, Azure, etc.) |
|
||||
| **Model** | Model to use (GPT-5, Claude Sonnet 4.5, local GGUF, etc.) |
|
||||
| **Temperature** | Creativity level (0 = focused, 1 = creative) |
|
||||
| **Max Tokens** | Maximum response length |
|
||||
| **System Prompt** | Bot personality and instructions |
|
||||
| **Knowledge Base** | Connected .gbkb for answers |
|
||||
|
||||
---
|
||||
|
||||
### Managing Prompts
|
||||
|
||||
Prompts are reusable text templates for AI interactions.
|
||||
|
||||
**Prompt Types:**
|
||||
|
||||
| Type | Purpose |
|
||||
|------|---------|
|
||||
| **System Prompt** | Bot personality/behavior |
|
||||
| **Task Prompt** | Specific task instructions |
|
||||
| **Template** | Reusable text with variables |
|
||||
|
||||
**Creating a Prompt:**
|
||||
|
||||
1. Click **+ New Prompt**
|
||||
2. Enter a name (e.g., "support-agent")
|
||||
3. Select type
|
||||
4. Write prompt content with optional `{{variables}}`
|
||||
5. Save and link to bots
|
||||
|
||||
**Example Prompt:**
|
||||
|
||||
```botserver/docs/src/chapter-04-gbui/apps/sources-prompt-example.txt
|
||||
You are a friendly and professional customer support agent
|
||||
for {{company_name}}.
|
||||
|
||||
## Your Personality
|
||||
- Be warm and empathetic
|
||||
- Use simple, clear language
|
||||
- Be patient and thorough
|
||||
|
||||
## Guidelines
|
||||
- Always verify customer identity before sharing account info
|
||||
- If unsure, search the knowledge base
|
||||
- Escalate complex issues to human agents
|
||||
- Never make promises about refunds or compensation
|
||||
Bot: I'll modify botserver. Looking at the login function...
|
||||
[Task created: Add error handling to login]
|
||||
```
|
||||
|
||||
---
|
||||
The system will:
|
||||
1. Clone or pull the latest code
|
||||
2. Analyze the relevant files
|
||||
3. Make the requested changes
|
||||
4. Create a commit or pull request
|
||||
|
||||
### Managing Templates
|
||||
### Repository Actions
|
||||
|
||||
Templates are pre-built bot packages you can reuse.
|
||||
|
||||
**Installed Templates:**
|
||||
|
||||
| Template | Description |
|
||||
|----------|-------------|
|
||||
| **📋 CRM** | Full CRM with leads, contacts |
|
||||
| **📋 Support** | Ticket management and customer service |
|
||||
| **📋 FAQ** | Answer common questions from KB |
|
||||
|
||||
**Available Templates:**
|
||||
|
||||
| Template | Description |
|
||||
|----------|-------------|
|
||||
| **📋 HR** | Employee self-service |
|
||||
| **📋 Analytics** | Dashboard and metrics |
|
||||
| **📋 Compliance** | LGPD, GDPR compliance |
|
||||
|
||||
**Template Contents:**
|
||||
|
||||
Templates include:
|
||||
- Dialog scripts (.bas files)
|
||||
- Bot configuration
|
||||
- Knowledge base documentation
|
||||
- Sample conversations
|
||||
| Action | Description |
|
||||
|--------|-------------|
|
||||
| **Browse** | View files and folders |
|
||||
| **Mention** | Insert @repo into chat |
|
||||
| **Disconnect** | Remove from Sources |
|
||||
| **Settings** | Configure branch, credentials |
|
||||
|
||||
---
|
||||
|
||||
### Managing Knowledge Bases
|
||||
## Apps
|
||||
|
||||
Knowledge bases store documents that your bot can search for answers.
|
||||
Apps are HTMX applications created with `CREATE SITE`. They appear here automatically.
|
||||
|
||||
### App Card
|
||||
|
||||
Each app shows:
|
||||
|
||||
| Field | Description |
|
||||
|-------|-------------|
|
||||
| **Documents** | Count of uploaded files |
|
||||
| **Size** | Total storage used |
|
||||
| **Last Indexed** | When content was last processed |
|
||||
| **Used By** | Bots connected to this KB |
|
||||
| **Name** | App name with @mention tag |
|
||||
| **Type** | HTMX, Dashboard, Site |
|
||||
| **Description** | Generated from creation prompt |
|
||||
| **URL** | Live endpoint (e.g., `/crm`) |
|
||||
| **Created** | When the app was generated |
|
||||
|
||||
**Uploading Documents:**
|
||||
### Using @mentions with Apps
|
||||
|
||||
1. Open the knowledge base
|
||||
2. Click **Upload** or drag files
|
||||
3. Organize into folders
|
||||
4. Click **Reindex** to process new content
|
||||
Reference apps to modify them:
|
||||
|
||||
**Supported Formats:**
|
||||
- PDF, DOCX, TXT, MD
|
||||
- CSV, XLSX
|
||||
- HTML, JSON
|
||||
```
|
||||
You: @crm change the submit button to green
|
||||
|
||||
Bot: I'll update the CRM app. Modifying the button styles...
|
||||
[Task created: Change submit button color]
|
||||
```
|
||||
|
||||
```
|
||||
You: @dashboard add a new KPI card for monthly revenue
|
||||
|
||||
Bot: I'll add that to your dashboard. Creating the KPI card...
|
||||
[Task created: Add monthly revenue KPI]
|
||||
```
|
||||
|
||||
### App Actions
|
||||
|
||||
| Action | Description |
|
||||
|--------|-------------|
|
||||
| **Open** | View app in new tab |
|
||||
| **Edit** | Open Tasks with app context |
|
||||
| **Mention** | Insert @app into chat |
|
||||
| **Delete** | Remove app and files |
|
||||
|
||||
---
|
||||
|
||||
## Import and Export
|
||||
## @Mention Autocomplete
|
||||
|
||||
### Exporting a Bot
|
||||
When typing in chat, `@` triggers autocomplete:
|
||||
|
||||
1. Click **⚙️** on the bot
|
||||
2. Select **Export**
|
||||
3. Choose what to include:
|
||||
- Bot configuration
|
||||
- Dialog scripts (.bas files)
|
||||
- Prompts
|
||||
- Knowledge base (optional, large)
|
||||
- Conversation history (optional)
|
||||
4. Select format: .gbai, ZIP, or JSON
|
||||
1. Type `@` to see suggestions
|
||||
2. Continue typing to filter (e.g., `@bot` shows `@botserver`, `@botui`)
|
||||
3. Press **Enter** or **Tab** to select
|
||||
4. Press **Escape** to cancel
|
||||
|
||||
### Importing a Bot
|
||||
### Mention Types
|
||||
|
||||
1. Click **Import** at the top
|
||||
2. Drop file or browse (supported: .gbai, .zip)
|
||||
3. Choose:
|
||||
- Create new bot, or
|
||||
- Replace existing bot
|
||||
4. Configure merge options for prompts and KB
|
||||
| Type | Icon | Example |
|
||||
|------|------|---------|
|
||||
| Repository | Git icon | `@botserver` |
|
||||
| App | Grid icon | `@mycrm` |
|
||||
|
||||
### Context for Tasks
|
||||
|
||||
When you mention a source, it becomes context for the task:
|
||||
|
||||
```
|
||||
You: @botserver @botui make the API response format consistent
|
||||
|
||||
Bot: I'll update both repositories to use consistent response formats.
|
||||
[Task created with context: botserver, botui]
|
||||
```
|
||||
|
||||
Without explicit mentions, Tasks uses recent context or asks for clarification.
|
||||
|
||||
---
|
||||
|
||||
## Prompts
|
||||
|
||||
System prompts define bot personality and behavior.
|
||||
|
||||
### Prompt Categories
|
||||
|
||||
| Category | Purpose |
|
||||
|----------|---------|
|
||||
| **Assistants** | Role-specific personas |
|
||||
| **Tools** | Tool descriptions for LLM |
|
||||
| **Personas** | Bot personality definitions |
|
||||
| **Custom** | Your own prompts |
|
||||
|
||||
### Creating a Prompt
|
||||
|
||||
1. Click **+ New Prompt**
|
||||
2. Enter name and category
|
||||
3. Write prompt content
|
||||
4. Use `{{variables}}` for dynamic values
|
||||
5. Click **Save**
|
||||
|
||||
### Prompt Actions
|
||||
|
||||
| Action | Description |
|
||||
|--------|-------------|
|
||||
| **Use** | Apply to current session |
|
||||
| **Copy** | Copy to clipboard |
|
||||
| **Save** | Add to collection |
|
||||
| **Edit** | Modify content |
|
||||
|
||||
---
|
||||
|
||||
## Templates
|
||||
|
||||
Bot packages ready to deploy.
|
||||
|
||||
### Available Templates
|
||||
|
||||
| Template | Description |
|
||||
|----------|-------------|
|
||||
| **CRM** | Customer relationship management |
|
||||
| **Support** | Helpdesk and ticketing |
|
||||
| **Analytics** | Dashboards and reports |
|
||||
| **Compliance** | LGPD, GDPR, HIPAA |
|
||||
|
||||
### Installing a Template
|
||||
|
||||
1. Click on template card
|
||||
2. Review contents
|
||||
3. Click **Install**
|
||||
4. Configure settings
|
||||
5. Bot is ready
|
||||
|
||||
---
|
||||
|
||||
## MCP Servers
|
||||
|
||||
Model Context Protocol servers extend bot capabilities. MCP servers are configured via `mcp.csv` in the bot's `.gbai` folder, making their tools available to Tasks just like BASIC keywords.
|
||||
|
||||
### The mcp.csv File
|
||||
|
||||
MCP servers are configured by adding entries to `mcp.csv` in your bot's `.gbai` folder:
|
||||
|
||||
```
|
||||
mybot.gbai/
|
||||
├── mybot.gbdialog/ # BASIC scripts
|
||||
├── mybot.gbdrive/ # Files and documents
|
||||
├── config.csv # Bot configuration
|
||||
├── attendant.csv # Attendant configuration
|
||||
└── mcp.csv # MCP server definitions
|
||||
```
|
||||
|
||||
When botserver starts, it reads the `mcp.csv` file and loads all server configurations.
|
||||
|
||||
### Server Card
|
||||
|
||||
| Field | Description |
|
||||
|-------|-------------|
|
||||
| **Name** | Server identifier (used for `USE MCP` calls) |
|
||||
| **Type** | filesystem, github, database, slack, etc. |
|
||||
| **Status** | Active, Inactive, Error |
|
||||
| **Tools** | Available tools count |
|
||||
| **Source** | "directory" (from .gbmcp) |
|
||||
|
||||
### mcp.csv Format
|
||||
|
||||
The CSV file has the following columns:
|
||||
|
||||
| Column | Required | Description |
|
||||
|--------|----------|-------------|
|
||||
| `name` | Yes | Unique server identifier |
|
||||
| `type` | Yes | Connection type: `stdio`, `http`, `websocket`, `tcp` |
|
||||
| `command` | Yes | For stdio: command. For http/ws: URL |
|
||||
| `args` | No | Command arguments (space-separated) |
|
||||
| `description` | No | Human-readable description |
|
||||
| `enabled` | No | `true` or `false` (default: `true`) |
|
||||
| `auth_type` | No | `none`, `api_key`, `bearer` |
|
||||
| `auth_env` | No | Environment variable for auth |
|
||||
|
||||
### Example mcp.csv
|
||||
|
||||
```csv
|
||||
name,type,command,args,description,enabled
|
||||
# MCP Server Configuration - lines starting with # are comments
|
||||
filesystem,stdio,npx,"-y @modelcontextprotocol/server-filesystem /data",Access local files,true
|
||||
github,stdio,npx,"-y @modelcontextprotocol/server-github",GitHub API,true,bearer,GITHUB_TOKEN
|
||||
postgres,stdio,npx,"-y @modelcontextprotocol/server-postgres",Database queries,false
|
||||
slack,stdio,npx,"-y @modelcontextprotocol/server-slack",Slack messaging,true,bearer,SLACK_BOT_TOKEN
|
||||
myapi,http,https://api.example.com/mcp,,Custom API,true,api_key,MY_API_KEY
|
||||
```
|
||||
|
||||
### Adding an MCP Server
|
||||
|
||||
**Method 1: Via UI**
|
||||
1. Click **+ Add Server**
|
||||
2. Enter server details
|
||||
3. Configure connection type (stdio, http, websocket)
|
||||
4. Test connection
|
||||
5. Click **Save**
|
||||
|
||||
**Method 2: Via mcp.csv**
|
||||
1. Open `mcp.csv` in your `.gbai` folder
|
||||
2. Add a new line with server configuration
|
||||
3. Restart bot or click **🔄 Reload** in Sources UI
|
||||
4. Server appears automatically
|
||||
|
||||
### Using MCP Tools in BASIC
|
||||
|
||||
```bas
|
||||
' Read a file using filesystem MCP server
|
||||
content = USE MCP "filesystem", "read_file", {"path": "/data/config.json"}
|
||||
|
||||
' Query database
|
||||
results = USE MCP "postgres", "query", {"sql": "SELECT * FROM users"}
|
||||
|
||||
' Send Slack message
|
||||
USE MCP "slack", "send_message", {"channel": "#general", "text": "Hello!"}
|
||||
```
|
||||
|
||||
### Connection Types
|
||||
|
||||
| Type | Description |
|
||||
|------|-------------|
|
||||
| **stdio** | Local process (npx, node, python) |
|
||||
| **http** | REST API endpoint |
|
||||
| **websocket** | WebSocket connection |
|
||||
| **tcp** | Raw TCP socket |
|
||||
|
||||
### Popular MCP Servers
|
||||
|
||||
| Server | Package | Description |
|
||||
|--------|---------|-------------|
|
||||
| Filesystem | `@modelcontextprotocol/server-filesystem` | File operations |
|
||||
| GitHub | `@modelcontextprotocol/server-github` | GitHub API |
|
||||
| PostgreSQL | `@modelcontextprotocol/server-postgres` | Database queries |
|
||||
| Slack | `@modelcontextprotocol/server-slack` | Messaging |
|
||||
|
||||
See [USE MCP](../../06-gbdialog/keyword-use-mcp.md) for complete documentation.
|
||||
|
||||
---
|
||||
|
||||
## LLM Tools
|
||||
|
||||
Tools that the LLM can invoke during conversations.
|
||||
|
||||
### Tool Sources
|
||||
|
||||
| Source | Description |
|
||||
|--------|-------------|
|
||||
| **Built-in** | Core BASIC keywords |
|
||||
| **MCP** | From connected MCP servers |
|
||||
| **Custom** | Your .bas files with DESCRIPTION |
|
||||
|
||||
### Tool Card
|
||||
|
||||
| Field | Description |
|
||||
|-------|-------------|
|
||||
| **Name** | Tool identifier |
|
||||
| **Description** | What it does |
|
||||
| **Parameters** | Required inputs |
|
||||
| **Source** | Where it comes from |
|
||||
|
||||
---
|
||||
|
||||
## Models
|
||||
|
||||
Configured AI models for the platform.
|
||||
|
||||
### Model Card
|
||||
|
||||
| Field | Description |
|
||||
|-------|-------------|
|
||||
| **Name** | Model identifier |
|
||||
| **Provider** | OpenAI, Anthropic, Local, etc. |
|
||||
| **Status** | Active, coming soon |
|
||||
| **Tags** | Capabilities (chat, code, vision) |
|
||||
|
||||
### Supported Providers
|
||||
|
||||
| Provider | Models |
|
||||
|----------|--------|
|
||||
| **OpenAI** | GPT-4, GPT-4o |
|
||||
| **Anthropic** | Claude Sonnet 4.5, Claude Opus 4 |
|
||||
| **Local** | llama.cpp GGUF models |
|
||||
| **Azure** | Azure OpenAI deployments |
|
||||
|
||||
---
|
||||
|
||||
## Search
|
||||
|
||||
Use the search box to find across all source types:
|
||||
|
||||
- Type to search by name
|
||||
- Results update as you type
|
||||
- Press **Enter** to search
|
||||
- Press **Escape** to clear
|
||||
|
||||
---
|
||||
|
||||
|
|
@ -184,165 +378,40 @@ Knowledge bases store documents that your bot can search for answers.
|
|||
|
||||
| Shortcut | Action |
|
||||
|----------|--------|
|
||||
| `Ctrl+N` | New bot |
|
||||
| `Ctrl+S` | Save changes |
|
||||
| `Ctrl+E` | Export selected |
|
||||
| `Ctrl+I` | Import |
|
||||
| `Delete` | Delete selected |
|
||||
| `Ctrl+D` | Duplicate |
|
||||
| `F2` | Rename |
|
||||
| `/` | Search |
|
||||
| `Ctrl+K` | Focus search |
|
||||
| `1-6` | Switch tabs |
|
||||
| `Escape` | Close modal |
|
||||
| `Enter` | Open selected |
|
||||
| `Escape` | Close dialog |
|
||||
|
||||
---
|
||||
|
||||
## Tips & Tricks
|
||||
|
||||
### Bot Management
|
||||
|
||||
💡 **Use descriptive names** - "customer-support-v2" is better than "bot1"
|
||||
|
||||
💡 **Keep prompts separate** - Reuse prompts across multiple bots
|
||||
|
||||
💡 **Version your exports** - Export before major changes
|
||||
|
||||
💡 **Test in Draft mode** - Don't go Live until fully tested
|
||||
|
||||
### Prompt Writing
|
||||
|
||||
💡 **Be specific** - Clear instructions give better results
|
||||
|
||||
💡 **Use examples** - Show the AI what good responses look like
|
||||
|
||||
💡 **Set boundaries** - Define what the bot should NOT do
|
||||
|
||||
💡 **Use variables** - Make prompts reusable with {{placeholders}}
|
||||
|
||||
### Knowledge Base
|
||||
|
||||
💡 **Organize in folders** - Group related documents together
|
||||
|
||||
💡 **Keep documents current** - Remove outdated information
|
||||
|
||||
💡 **Use clear filenames** - "refund-policy-2025.pdf" not "doc1.pdf"
|
||||
|
||||
💡 **Reindex after changes** - New content isn't searchable until indexed
|
||||
|
||||
---
|
||||
|
||||
## Troubleshooting
|
||||
|
||||
### Bot not responding
|
||||
|
||||
**Possible causes:**
|
||||
1. Bot is in Draft mode
|
||||
2. AI provider not configured
|
||||
3. No dialogs or prompts set up
|
||||
|
||||
**Solution:**
|
||||
1. Check bot status is "Live"
|
||||
2. Verify AI settings have valid API key
|
||||
3. Ensure at least start.bas exists
|
||||
4. Check error logs in Analytics
|
||||
|
||||
---
|
||||
|
||||
### Knowledge base not finding answers
|
||||
|
||||
**Possible causes:**
|
||||
1. Documents not indexed
|
||||
2. Document format not supported
|
||||
3. Query doesn't match content
|
||||
|
||||
**Solution:**
|
||||
1. Click "Reindex" and wait for completion
|
||||
2. Convert documents to supported formats
|
||||
3. Check document actually contains the information
|
||||
4. Try different phrasing
|
||||
|
||||
---
|
||||
|
||||
### Import fails
|
||||
|
||||
**Possible causes:**
|
||||
1. File corrupted
|
||||
2. Incompatible version
|
||||
3. Duplicate bot ID
|
||||
|
||||
**Solution:**
|
||||
1. Try re-exporting from source
|
||||
2. Check General Bots version compatibility
|
||||
3. Choose "Create new bot" instead of replace
|
||||
4. Rename bot ID if duplicate
|
||||
|
||||
---
|
||||
|
||||
### Prompts not applying
|
||||
|
||||
**Possible causes:**
|
||||
1. Prompt not linked to bot
|
||||
2. Variable not defined
|
||||
3. Syntax error in prompt
|
||||
|
||||
**Solution:**
|
||||
1. Check AI Settings → System Prompt selection
|
||||
2. Verify all {{variables}} have values
|
||||
3. Test prompt with "Test" button
|
||||
4. Check for unclosed brackets or quotes
|
||||
|
||||
---
|
||||
|
||||
## BASIC Integration
|
||||
|
||||
Access Sources data from dialogs:
|
||||
### List Repositories
|
||||
|
||||
### Get Bot Configuration
|
||||
|
||||
```botserver/docs/src/chapter-04-gbui/apps/sources-config.basic
|
||||
config = GET BOT CONFIG
|
||||
TALK "Bot name: " + config.displayName
|
||||
TALK "Language: " + config.language
|
||||
```bas
|
||||
repos = GET REPOSITORIES
|
||||
FOR EACH repo IN repos
|
||||
TALK repo.name + " - " + repo.description
|
||||
NEXT
|
||||
```
|
||||
|
||||
### Use Prompts
|
||||
### List Apps
|
||||
|
||||
```botserver/docs/src/chapter-04-gbui/apps/sources-prompts.basic
|
||||
' Load a prompt template
|
||||
prompt = GET PROMPT "summarize"
|
||||
|
||||
' Use with variables
|
||||
summary = GENERATE WITH PROMPT prompt, content
|
||||
TALK summary
|
||||
```bas
|
||||
apps = GET APPS
|
||||
FOR EACH app IN apps
|
||||
TALK app.name + " at /" + app.url
|
||||
NEXT
|
||||
```
|
||||
|
||||
### Search Knowledge Base
|
||||
### Get Task Context
|
||||
|
||||
```botserver/docs/src/chapter-04-gbui/apps/sources-search.basic
|
||||
HEAR question AS TEXT "What would you like to know?"
|
||||
|
||||
results = SEARCH KB question IN "support.gbkb"
|
||||
|
||||
IF COUNT(results) > 0 THEN
|
||||
TALK results[0].answer
|
||||
TALK "Source: " + results[0].source
|
||||
ELSE
|
||||
TALK "I couldn't find information about that."
|
||||
END IF
|
||||
```
|
||||
|
||||
### List Available Bots
|
||||
|
||||
```botserver/docs/src/chapter-04-gbui/apps/sources-list.basic
|
||||
bots = GET BOTS
|
||||
|
||||
TALK "Available bots:"
|
||||
FOR EACH bot IN bots
|
||||
IF bot.status = "live" THEN
|
||||
TALK "● " + bot.displayName
|
||||
ELSE
|
||||
TALK "○ " + bot.displayName + " (draft)"
|
||||
END IF
|
||||
```bas
|
||||
' Get sources mentioned in current conversation
|
||||
context = GET TASK CONTEXT
|
||||
FOR EACH source IN context
|
||||
TALK "Working with: @" + source.name
|
||||
NEXT
|
||||
```
|
||||
|
||||
|
|
@ -350,7 +419,6 @@ NEXT
|
|||
|
||||
## See Also
|
||||
|
||||
- [Designer App](./designer.md) - Visual flow builder
|
||||
- [Drive App](./drive.md) - Upload KB documents
|
||||
- [How To: Create Your First Bot](../how-to/create-first-bot.md)
|
||||
- [How To: Add Documents to Knowledge Base](../how-to/add-kb-documents.md)
|
||||
- [Tasks](./tasks.md) - Execute work on repositories and apps
|
||||
- [Chat](./chat.md) - Use @mentions in conversation
|
||||
- [Autonomous Task AI](../../07-gbapp/autonomous-tasks.md) - How context flows to tasks
|
||||
|
|
@ -22,7 +22,7 @@ The Suite includes integrated applications:
|
|||
|-----|---------|
|
||||
| 💬 Chat | AI assistant conversations |
|
||||
| 📁 Drive | File management |
|
||||
| ✓ Tasks | To-do lists |
|
||||
| ⚡ Tasks | LLM-powered intelligent execution |
|
||||
| ✉ Mail | Email client |
|
||||
| 📅 Calendar | Scheduling |
|
||||
| 🎥 Meet | Video calls |
|
||||
|
|
|
|||
|
|
@ -1,84 +1,212 @@
|
|||
# Tasks
|
||||
|
||||
> **Your personal to-do list**
|
||||
> **The machine does the work**
|
||||
|
||||
---
|
||||
|
||||
<img src="../../assets/chapter-04/autotask-interface.svg" alt="Tasks Interface" style="max-width: 100%; height: auto;">
|
||||
|
||||
## What is Tasks?
|
||||
|
||||
Tasks helps you keep track of what you need to do. Add tasks, check them off when done, and stay organized.
|
||||
Tasks is where the machine does the work for you. Instead of manually tracking to-do items, you describe what you want to accomplish in natural language, and the system compiles your intent into an executable plan with automatic step-by-step execution.
|
||||
|
||||
| Old Way | Tasks Way |
|
||||
|---------|-----------|
|
||||
| Create a task | Describe your goal |
|
||||
| Do it yourself | Machine plans it |
|
||||
| Mark complete | Machine executes it |
|
||||
| Repeat | You approve critical steps |
|
||||
|
||||
---
|
||||
|
||||
## Adding a Task
|
||||
## How It Works
|
||||
|
||||
1. Type what you need to do in the text box
|
||||
2. Click **+ Add Task** or press **Enter**
|
||||
|
||||
That's it! Your task appears in the list.
|
||||
|
||||
### Optional: Add More Details
|
||||
|
||||
Before clicking Add, you can:
|
||||
|
||||
- **Pick a category** - Work, Personal, Shopping, or Health
|
||||
- **Set a due date** - Click the calendar icon
|
||||
| Step | What Happens |
|
||||
|------|--------------|
|
||||
| **1. Describe** | Write what you want in plain English |
|
||||
| **2. Compile** | LLM analyzes intent, generates execution plan |
|
||||
| **3. Review** | See steps, estimates, risks before execution |
|
||||
| **4. Execute** | System runs the plan, pausing for approvals |
|
||||
| **5. Monitor** | Watch progress, make decisions when needed |
|
||||
|
||||
---
|
||||
|
||||
## Completing Tasks
|
||||
## Creating a Task
|
||||
|
||||
Click the **checkbox** next to any task to mark it done.
|
||||
### Write Your Intent
|
||||
|
||||
Done tasks get a strikethrough and move to the Completed tab.
|
||||
In the intent box, describe what you want to accomplish:
|
||||
|
||||
**Changed your mind?** Click the checkbox again to un-complete it.
|
||||
| Good Examples |
|
||||
|---------------|
|
||||
| "Make a financial CRM for Deloitte with client management and reporting" |
|
||||
| "Create a website that collects leads and sends them to Salesforce" |
|
||||
| "Build an automated email campaign for our product launch" |
|
||||
| "Analyze Q4 sales data and generate a PDF report with charts" |
|
||||
|
||||
**Tips for better results:**
|
||||
|
||||
- Be specific about the outcome you want
|
||||
- Mention the client or project name
|
||||
- Include key features or requirements
|
||||
- Specify integrations if needed
|
||||
|
||||
### Choose Execution Mode
|
||||
|
||||
| Mode | Best For | How It Works |
|
||||
|------|----------|--------------|
|
||||
| **Semi-Automatic** | Most tasks | Runs automatically, pauses for high-risk steps |
|
||||
| **Supervised** | Learning/sensitive | Pauses before each step for your approval |
|
||||
| **Fully Automatic** | Trusted workflows | Runs everything without stopping |
|
||||
| **Dry Run** | Testing | Simulates execution without making changes |
|
||||
|
||||
### Set Priority
|
||||
|
||||
| Priority | Meaning |
|
||||
|----------|---------|
|
||||
| **Critical** | Urgent, run immediately |
|
||||
| **High** | Important, prioritize |
|
||||
| **Medium** | Normal priority (default) |
|
||||
| **Low** | Run when resources available |
|
||||
| **Background** | Run during idle time |
|
||||
|
||||
### Click Compile & Plan
|
||||
|
||||
The LLM will:
|
||||
|
||||
1. Extract entities (action, target, domain, client)
|
||||
2. Generate an execution plan with ordered steps
|
||||
3. Assess risks and estimate resources
|
||||
4. Generate the underlying BASIC program
|
||||
|
||||
---
|
||||
|
||||
## Task Priority
|
||||
## Understanding the Execution Plan
|
||||
|
||||
Click the **star** ⭐ on any task to mark it as important.
|
||||
After compilation, you see a detailed plan:
|
||||
|
||||
Starred tasks appear in the **Priority** tab for quick access.
|
||||
### Plan Header
|
||||
|
||||
| Field | Description |
|
||||
|-------|-------------|
|
||||
| **Plan Name** | Auto-generated title for your task |
|
||||
| **Description** | Summary of what will be accomplished |
|
||||
| **Confidence** | How confident the LLM is in the plan (aim for 80%+) |
|
||||
| **Risk Level** | Overall risk assessment (None/Low/Medium/High/Critical) |
|
||||
| **Estimated Duration** | How long execution should take |
|
||||
| **Estimated Cost** | API and compute costs |
|
||||
|
||||
### Execution Steps
|
||||
|
||||
Each step shows:
|
||||
|
||||
| Field | Description |
|
||||
|-------|-------------|
|
||||
| **Step Number** | Order of execution |
|
||||
| **Priority** | CRITICAL, HIGH, MEDIUM, LOW |
|
||||
| **Step Name** | What this step does |
|
||||
| **Keywords** | BASIC keywords that will be used |
|
||||
| **Risk Level** | Risk for this specific step |
|
||||
|
||||
### Plan Actions
|
||||
|
||||
| Button | Action |
|
||||
|--------|--------|
|
||||
| **Discard** | Delete the plan, start over |
|
||||
| **Edit Plan** | Modify steps before execution |
|
||||
| **Simulate** | Preview impact without executing |
|
||||
| **Execute** | Start running the plan |
|
||||
|
||||
---
|
||||
|
||||
## Filtering Your Tasks
|
||||
## Monitoring Tasks
|
||||
|
||||
Use the tabs at the top to see different views:
|
||||
### Task States
|
||||
|
||||
| Tab | What You See |
|
||||
|-----|--------------|
|
||||
| **All** | Everything |
|
||||
| **Active** | Tasks not done yet |
|
||||
| **Completed** | Tasks you finished |
|
||||
| **Priority** | Starred tasks only |
|
||||
| Status | Meaning |
|
||||
|--------|---------|
|
||||
| **Draft** | Created, not yet compiled |
|
||||
| **Compiling** | LLM is generating the plan |
|
||||
| **Ready** | Plan generated, waiting to start |
|
||||
| **Running** | Currently executing |
|
||||
| **Paused** | Execution paused by user |
|
||||
| **Pending Approval** | Waiting for you to approve a step |
|
||||
| **Waiting Decision** | Needs your input to continue |
|
||||
| **Completed** | Successfully finished |
|
||||
| **Failed** | Encountered an error |
|
||||
| **Cancelled** | Stopped by user |
|
||||
|
||||
### Filter Tabs
|
||||
|
||||
| Tab | Shows |
|
||||
|-----|-------|
|
||||
| **All** | Every task regardless of status |
|
||||
| **Running** | Currently executing tasks |
|
||||
| **Need Approval** | Tasks waiting for your approval |
|
||||
| **Decisions** | Tasks needing your input |
|
||||
|
||||
### Progress Tracking
|
||||
|
||||
Each task shows:
|
||||
|
||||
- Current step number and name
|
||||
- Progress bar with percentage
|
||||
- Time elapsed and estimated remaining
|
||||
|
||||
---
|
||||
|
||||
## Editing a Task
|
||||
## Approvals & Decisions
|
||||
|
||||
1. Click on the task text
|
||||
2. Type your changes
|
||||
3. Press **Enter** to save or **Escape** to cancel
|
||||
### When Approvals Are Required
|
||||
|
||||
High-impact actions require your approval:
|
||||
|
||||
- Sending emails to many recipients
|
||||
- Modifying production databases
|
||||
- Making external API calls with side effects
|
||||
- Deploying to live environments
|
||||
- Actions exceeding cost thresholds
|
||||
|
||||
### Approval Dialog
|
||||
|
||||
When approval is needed, you see:
|
||||
|
||||
| Field | Description |
|
||||
|-------|-------------|
|
||||
| **Action description** | What will happen |
|
||||
| **Impact summary** | What could be affected |
|
||||
| **Risk level** | How risky this step is |
|
||||
| **Simulation result** | Preview of the outcome |
|
||||
|
||||
**Options:**
|
||||
|
||||
| Action | Result |
|
||||
|--------|--------|
|
||||
| **Approve** | Continue execution |
|
||||
| **Defer** | Decide later |
|
||||
| **Reject** | Skip this step or stop execution |
|
||||
|
||||
### Making Decisions
|
||||
|
||||
Sometimes the system needs your input:
|
||||
|
||||
- Choosing between alternative approaches
|
||||
- Selecting from multiple options
|
||||
- Providing missing information
|
||||
|
||||
Each option shows pros, cons, and impact estimates.
|
||||
|
||||
---
|
||||
|
||||
## Deleting a Task
|
||||
## Task Actions
|
||||
|
||||
Click the **trash icon** 🗑️ on the right side of any task.
|
||||
|
||||
**Note:** This cannot be undone!
|
||||
|
||||
---
|
||||
|
||||
## Keyboard Shortcuts
|
||||
|
||||
| Press | What Happens |
|
||||
|-------|--------------|
|
||||
| `Enter` | Add task (when typing) |
|
||||
| `Escape` | Cancel editing |
|
||||
| Action | When Available | What It Does |
|
||||
|--------|----------------|--------------|
|
||||
| **Details** | Always | View full task information |
|
||||
| **Simulate** | Before execution | Preview impact |
|
||||
| **Pause** | While running | Temporarily stop execution |
|
||||
| **Resume** | When paused | Continue execution |
|
||||
| **Cancel** | Anytime | Stop and discard task |
|
||||
|
||||
---
|
||||
|
||||
|
|
@ -86,41 +214,117 @@ Click the **trash icon** 🗑️ on the right side of any task.
|
|||
|
||||
You can also create tasks by talking to your bot:
|
||||
|
||||
**You:** "Remind me to call John tomorrow"
|
||||
**You:** "I need to build a customer portal for Acme Corp"
|
||||
|
||||
**Bot:** "✅ Task created: Call John - Due: Tomorrow"
|
||||
**Bot:** "I'll create a task for that. Here's the plan:
|
||||
- 5 steps, estimated 3 hours
|
||||
- Includes: database setup, authentication, dashboard, API integration
|
||||
- Risk: Low
|
||||
|
||||
**You:** "What tasks do I have today?"
|
||||
Should I execute this plan?"
|
||||
|
||||
**Bot:** "You have 3 tasks for today..."
|
||||
**You:** "Yes, go ahead"
|
||||
|
||||
**Bot:** "Task started. I'll notify you when approvals are needed."
|
||||
|
||||
---
|
||||
|
||||
## Tips
|
||||
## Generated BASIC Code
|
||||
|
||||
- **Keep it simple** - Short task names are easier to scan
|
||||
- **Use categories** - Helps you focus on one area at a time
|
||||
- **Check daily** - Review your Active tasks each morning
|
||||
- **Celebrate wins** - Look at Completed to see your progress!
|
||||
Every task generates a BASIC program behind the scenes. You can view and copy this code:
|
||||
|
||||
```bas
|
||||
' AUTO-GENERATED BASIC PROGRAM
|
||||
' Plan: Financial CRM for Deloitte
|
||||
|
||||
PLAN_START "Financial CRM", "Client management system"
|
||||
STEP 1, "Create database schema", CRITICAL
|
||||
STEP 2, "Setup authentication", HIGH
|
||||
STEP 3, "Build client module", HIGH
|
||||
PLAN_END
|
||||
|
||||
NEW_TABLE "clients"
|
||||
COLUMN "name", STRING
|
||||
COLUMN "email", STRING
|
||||
COLUMN "revenue", DECIMAL
|
||||
SAVE_TABLE
|
||||
```
|
||||
|
||||
This code can be:
|
||||
|
||||
- Copied for manual execution
|
||||
- Modified and saved as a template
|
||||
- Reused for similar projects
|
||||
|
||||
---
|
||||
|
||||
## Best Practices
|
||||
|
||||
### Writing Good Intents
|
||||
|
||||
| Do | Don't |
|
||||
|----|-------|
|
||||
| "Create a sales dashboard for Q4 data with charts showing revenue by region" | "Make something" |
|
||||
| "Build an email drip campaign: welcome email, 3-day follow-up, 7-day offer" | "Do the thing we discussed" |
|
||||
| "Analyze customer feedback CSV and generate sentiment report" | "Fix it" |
|
||||
|
||||
### Choosing Execution Mode
|
||||
|
||||
| Situation | Recommended Mode |
|
||||
|-----------|------------------|
|
||||
| New to Tasks | Supervised |
|
||||
| Routine tasks | Semi-Automatic |
|
||||
| Trusted, tested workflows | Fully Automatic |
|
||||
| Experimenting | Dry Run |
|
||||
|
||||
### Managing Risk
|
||||
|
||||
- Review the risk assessment before executing
|
||||
- Use Simulate for high-risk tasks
|
||||
- Set up approval thresholds in settings
|
||||
- Monitor running tasks actively
|
||||
|
||||
---
|
||||
|
||||
## Troubleshooting
|
||||
|
||||
### My task didn't save
|
||||
- Check your internet connection
|
||||
- Refresh the page and try again
|
||||
### Compilation Failed
|
||||
|
||||
### I can't find my task
|
||||
- Check the **All** tab (not just Active)
|
||||
- Try scrolling down if you have many tasks
|
||||
- Check that your intent is clear and specific
|
||||
- Avoid ambiguous language
|
||||
- Include necessary context (client name, data sources)
|
||||
|
||||
### Stats show wrong numbers
|
||||
- Refresh the page
|
||||
### Task Stuck on Running
|
||||
|
||||
- Check if an approval is pending
|
||||
- Look for decision requests
|
||||
- Review the execution log for errors
|
||||
|
||||
### Unexpected Results
|
||||
|
||||
- Review the generated plan before executing
|
||||
- Use Dry Run to test first
|
||||
- Check the BASIC code for issues
|
||||
|
||||
---
|
||||
|
||||
## Settings
|
||||
|
||||
Configure Tasks behavior in Settings:
|
||||
|
||||
| Setting | Description |
|
||||
|---------|-------------|
|
||||
| **Default execution mode** | Your preferred mode |
|
||||
| **Approval thresholds** | When to require approval |
|
||||
| **Cost limits** | Maximum spend per task |
|
||||
| **Notification preferences** | How to alert you |
|
||||
| **Auto-cleanup** | Remove completed tasks after X days |
|
||||
|
||||
---
|
||||
|
||||
## See Also
|
||||
|
||||
- [Calendar](./calendar.md) - Tasks with due dates show here too
|
||||
- [Chat](./chat.md) - Create tasks by talking to your bot
|
||||
- [Autonomous Task AI](../../07-gbapp/autonomous-tasks.md) - Architecture details
|
||||
- [CREATE SITE](../../06-gbdialog/keyword-create-site.md) - App generation
|
||||
- [Calendar](./calendar.md) - Scheduled tasks
|
||||
- [Chat](./chat.md) - Create tasks through conversation
|
||||
|
|
@ -1,21 +1,21 @@
|
|||
# Console Mode
|
||||
|
||||
The BotServer console mode provides a text-based interface for monitoring your bot's operation directly in the terminal.
|
||||
The botserver console mode provides a text-based interface for monitoring your bot's operation directly in the terminal.
|
||||
|
||||
## Starting Console Mode
|
||||
|
||||
```bash
|
||||
# Start BotServer with console UI
|
||||
# Start botserver with console UI
|
||||
./botserver --console
|
||||
```
|
||||
|
||||
## Console Interface
|
||||
|
||||
The console displays real-time information about your running BotServer instance:
|
||||
The console displays real-time information about your running botserver instance:
|
||||
|
||||
```
|
||||
╔════════════════════════════════════════════════════════════╗
|
||||
║ BotServer Console ║
|
||||
║ botserver Console ║
|
||||
╠════════════════════════════════════════════════════════════╣
|
||||
║ Status: Running ║
|
||||
║ Uptime: 2h 34m 12s ║
|
||||
|
|
@ -104,4 +104,4 @@ Display problems can often be resolved by trying a different terminal emulator.
|
|||
|
||||
## Summary
|
||||
|
||||
Console mode provides a simple, lightweight way to monitor BotServer status without needing a web browser. It's ideal for quick checks and basic monitoring, but for full functionality including interactive bot testing and detailed analytics, use the web interface.
|
||||
Console mode provides a simple, lightweight way to monitor botserver status without needing a web browser. It's ideal for quick checks and basic monitoring, but for full functionality including interactive bot testing and detailed analytics, use the web interface.
|
||||
|
|
@ -6,24 +6,7 @@
|
|||
|
||||
---
|
||||
|
||||
```
|
||||
┌─────────────────────────────────────────────────────────────────────────┐
|
||||
│ │
|
||||
│ ┌─────────────────────────────────────────────────────────────────┐ │
|
||||
│ │ │ │
|
||||
│ │ 📚 ADD DOCUMENTS TO KNOWLEDGE BASE │ │
|
||||
│ │ │ │
|
||||
│ │ ┌─────────┐ ┌─────────┐ ┌─────────┐ ┌─────────┐ │ │
|
||||
│ │ │ Step │───▶│ Step │───▶│ Step │───▶│ Step │ │ │
|
||||
│ │ │ 1 │ │ 2 │ │ 3 │ │ 4 │ │ │
|
||||
│ │ │Prepare │ │ Upload │ │ Index │ │ Test │ │ │
|
||||
│ │ │ Docs │ │ Files │ │ KB │ │ KB │ │ │
|
||||
│ │ └─────────┘ └─────────┘ └─────────┘ └─────────┘ │ │
|
||||
│ │ │ │
|
||||
│ └─────────────────────────────────────────────────────────────────┘ │
|
||||
│ │
|
||||
└─────────────────────────────────────────────────────────────────────────┘
|
||||
```
|
||||
<img src="../../assets/chapter-04/step-flow-4-steps.svg" alt="Add Documents to KB - 4 Step Process" style="max-width: 100%; height: auto;">
|
||||
|
||||
---
|
||||
|
||||
|
|
@ -57,36 +40,7 @@ Before you begin, make sure you have:
|
|||
|
||||
A **Knowledge Base (KB)** is a collection of documents that your bot uses to answer questions. When a user asks something, the bot searches through these documents to find relevant information.
|
||||
|
||||
```
|
||||
┌─────────────────────────────────────────────────────────────────────────┐
|
||||
│ HOW KNOWLEDGE BASE WORKS │
|
||||
├─────────────────────────────────────────────────────────────────────────┤
|
||||
│ │
|
||||
│ User asks: "What is our refund policy?" │
|
||||
│ │ │
|
||||
│ ▼ │
|
||||
│ ┌─────────────────────────────────────────────────────────────┐ │
|
||||
│ │ 🔍 Semantic Search │ │
|
||||
│ │ Searches through all documents in the knowledge base │ │
|
||||
│ └────────────────────────┬────────────────────────────────────┘ │
|
||||
│ │ │
|
||||
│ ┌───────────────────┼───────────────────┐ │
|
||||
│ ▼ ▼ ▼ │
|
||||
│ ┌─────────┐ ┌─────────┐ ┌─────────┐ │
|
||||
│ │policies │ │ FAQ │ │ terms │ │
|
||||
│ │ .pdf │ │ .docx │ │ .md │ │
|
||||
│ └────┬────┘ └─────────┘ └─────────┘ │
|
||||
│ │ │
|
||||
│ ▼ Found match! │
|
||||
│ ┌─────────────────────────────────────────────────────────────┐ │
|
||||
│ │ "Refunds are available within 30 days of purchase..." │ │
|
||||
│ └─────────────────────────────────────────────────────────────┘ │
|
||||
│ │ │
|
||||
│ ▼ │
|
||||
│ Bot answers with context from the document │
|
||||
│ │
|
||||
└─────────────────────────────────────────────────────────────────────────┘
|
||||
```
|
||||
<img src="../../assets/chapter-04/kb-semantic-search-flow.svg" alt="Knowledge Base Semantic Search Flow" style="max-width: 100%; height: auto;">
|
||||
|
||||
---
|
||||
|
||||
|
|
|
|||
|
|
@ -6,24 +6,7 @@
|
|||
|
||||
---
|
||||
|
||||
```
|
||||
┌─────────────────────────────────────────────────────────────────────────┐
|
||||
│ │
|
||||
│ ┌─────────────────────────────────────────────────────────────────┐ │
|
||||
│ │ │ │
|
||||
│ │ 📱 CONNECT WHATSAPP TO YOUR BOT │ │
|
||||
│ │ │ │
|
||||
│ │ ┌─────────┐ ┌─────────┐ ┌─────────┐ ┌─────────┐ │ │
|
||||
│ │ │ Step │───▶│ Step │───▶│ Step │───▶│ Step │ │ │
|
||||
│ │ │ 1 │ │ 2 │ │ 3 │ │ 4 │ │ │
|
||||
│ │ │ Meta │ │ Create │ │Configure│ │ Test │ │ │
|
||||
│ │ │ Account │ │ App │ │ Bot │ │ Channel │ │ │
|
||||
│ │ └─────────┘ └─────────┘ └─────────┘ └─────────┘ │ │
|
||||
│ │ │ │
|
||||
│ └─────────────────────────────────────────────────────────────────┘ │
|
||||
│ │
|
||||
└─────────────────────────────────────────────────────────────────────────┘
|
||||
```
|
||||
<img src="../../assets/chapter-04/step-flow-4-steps.svg" alt="Connect WhatsApp - 4 Step Process" style="max-width: 100%; height: auto;">
|
||||
|
||||
---
|
||||
|
||||
|
|
@ -56,38 +39,7 @@ Before you begin, make sure you have:
|
|||
|
||||
## Understanding WhatsApp Integration
|
||||
|
||||
```
|
||||
┌─────────────────────────────────────────────────────────────────────────┐
|
||||
│ HOW WHATSAPP INTEGRATION WORKS │
|
||||
├─────────────────────────────────────────────────────────────────────────┤
|
||||
│ │
|
||||
│ User sends message on WhatsApp │
|
||||
│ │ │
|
||||
│ ▼ │
|
||||
│ ┌─────────────────────────────────────────────────────────────┐ │
|
||||
│ │ WhatsApp Cloud API │ │
|
||||
│ │ (Meta's servers receive message) │ │
|
||||
│ └────────────────────────┬────────────────────────────────────┘ │
|
||||
│ │ │
|
||||
│ │ Webhook │
|
||||
│ ▼ │
|
||||
│ ┌─────────────────────────────────────────────────────────────┐ │
|
||||
│ │ General Bots Server │ │
|
||||
│ │ (Your bot processes the message) │ │
|
||||
│ └────────────────────────┬────────────────────────────────────┘ │
|
||||
│ │ │
|
||||
│ │ API Call │
|
||||
│ ▼ │
|
||||
│ ┌─────────────────────────────────────────────────────────────┐ │
|
||||
│ │ WhatsApp Cloud API │ │
|
||||
│ │ (Sends reply to user) │ │
|
||||
│ └────────────────────────┬────────────────────────────────────┘ │
|
||||
│ │ │
|
||||
│ ▼ │
|
||||
│ User receives bot response on WhatsApp │
|
||||
│ │
|
||||
└─────────────────────────────────────────────────────────────────────────┘
|
||||
```
|
||||
<img src="../../assets/chapter-04/whatsapp-integration-flow.svg" alt="WhatsApp Integration Flow" style="max-width: 100%; height: auto;">
|
||||
|
||||
---
|
||||
|
||||
|
|
|
|||
|
|
@ -64,7 +64,7 @@ Your General Bots deployment is a **living system** of interconnected components
|
|||
|
||||
| Component | Purpose | Status Indicators |
|
||||
|-----------|---------|-------------------|
|
||||
| **BotServer** | Core application, handles all requests | Response time, active sessions |
|
||||
| **botserver** | Core application, handles all requests | Response time, active sessions |
|
||||
| **PostgreSQL** | Primary database, stores users & config | Connections, query rate |
|
||||
| **Qdrant** | Vector database, powers semantic search | Vector count, search latency |
|
||||
| **MinIO** | File storage, manages documents | Storage used, object count |
|
||||
|
|
|
|||
|
|
@ -6,11 +6,11 @@ The Monitoring Dashboard is the **live operations homepage** for your General Bo
|
|||
|
||||
<img src="../assets/suite/live-monitoring-organism.svg" alt="Live Monitoring Dashboard" style="max-width: 100%; height: auto;">
|
||||
|
||||
The dashboard displays BotServer at the center orchestrating all interactions, with animated data packets flowing between components:
|
||||
The dashboard displays botserver at the center orchestrating all interactions, with animated data packets flowing between components:
|
||||
|
||||
- **Left Side (Data Layer)**: PostgreSQL, Qdrant vector database, and MinIO storage
|
||||
- **Right Side (Services)**: BotModels AI, Cache, and Vault security
|
||||
- **Center**: BotServer core with pulsing rings indicating activity
|
||||
- **Center**: botserver core with pulsing rings indicating activity
|
||||
- **Top**: Real-time metrics panels for sessions, messages, and response time
|
||||
- **Bottom**: Resource utilization bars and activity ticker
|
||||
|
||||
|
|
@ -302,7 +302,7 @@ Latest: User enrolled in Computer Science course
|
|||
1. Wait 5-10 seconds for initial data load
|
||||
2. Check network tab for failed API requests
|
||||
3. Verify all services are running
|
||||
4. Check BotServer logs for errors
|
||||
4. Check botserver logs for errors
|
||||
|
||||
### Animations Stuttering
|
||||
|
||||
|
|
|
|||
|
|
@ -40,7 +40,7 @@ Click the **nine-dot grid** (⋮⋮⋮) in the top right to see all applications
|
|||
|------|-----|--------------|
|
||||
| 💬 | **Chat** | Talk with your AI assistant |
|
||||
| 📁 | **Drive** | Store and manage your files |
|
||||
| ✓ | **Tasks** | Manage your to-do lists |
|
||||
| ⚡ | **Tasks** | LLM-powered intelligent task execution |
|
||||
| ✉ | **Mail** | Send and receive emails |
|
||||
| 📅 | **Calendar** | Schedule meetings and events |
|
||||
| 🎥 | **Meet** | Video calls and meetings |
|
||||
|
|
@ -179,54 +179,78 @@ Drive is your file storage - like Google Drive or OneDrive. Store documents, ima
|
|||
|
||||
---
|
||||
|
||||
## Part IV: Tasks - To-Do Management
|
||||
## Part IV: Tasks - LLM-Powered Execution
|
||||
|
||||
### What Tasks Does
|
||||
|
||||
Tasks helps you track what needs to be done. Create to-do lists, set due dates, and mark items complete.
|
||||
Tasks revolutionizes how you work. Instead of manually tracking to-do items, you describe what you want to accomplish in natural language, and the LLM compiles your intent into an executable plan with automatic step-by-step execution.
|
||||
|
||||
### The Tasks Interface
|
||||
|
||||
<img src="../assets/chapter-04/tasks-interface.svg" alt="Tasks Interface" style="max-width: 100%; height: auto;">
|
||||
<img src="../assets/chapter-04/autotask-interface.svg" alt="Tasks Interface" style="max-width: 100%; height: auto;">
|
||||
|
||||
### Adding a Task
|
||||
### Creating an Task
|
||||
|
||||
1. Type your task in the input box
|
||||
2. *(Optional)* Select a category: Work, Personal, Shopping, Health
|
||||
3. *(Optional)* Set a due date
|
||||
4. Click **+ Add** or press Enter
|
||||
1. **Describe your intent** in the text area (e.g., "Build a CRM for Deloitte with client management")
|
||||
2. **Choose execution mode:**
|
||||
- **Semi-Automatic** (recommended) - Runs automatically, pauses for high-risk steps
|
||||
- **Supervised** - Pauses before each step for your approval
|
||||
- **Fully Automatic** - Runs everything without stopping
|
||||
- **Dry Run** - Simulates execution without making changes
|
||||
3. **Set priority:** Critical, High, Medium, Low, or Background
|
||||
4. Click **🚀 Compile & Plan**
|
||||
|
||||
**Pro tip:** Be specific! Instead of "Work on project", write "Draft introduction section for project proposal"
|
||||
**Pro tip:** Be specific about outcomes! Instead of "make something", write "Create a sales dashboard with revenue charts by region and export to PDF"
|
||||
|
||||
### Task Priorities
|
||||
### Understanding the Plan
|
||||
|
||||
| Color | Priority | When to Use |
|
||||
|-------|----------|-------------|
|
||||
| 🔴 Red | High | Must do today |
|
||||
| 🟡 Yellow | Medium | Important but not urgent |
|
||||
| 🟢 Green | Low | Can wait |
|
||||
After compilation, you'll see:
|
||||
|
||||
### Completing Tasks
|
||||
| Element | What It Shows |
|
||||
|---------|---------------|
|
||||
| **Confidence** | How confident the LLM is (aim for 80%+) |
|
||||
| **Risk Level** | None / Low / Medium / High / Critical |
|
||||
| **Duration** | Estimated execution time |
|
||||
| **Cost** | API and compute costs |
|
||||
| **Steps** | Ordered execution plan with keywords |
|
||||
|
||||
- **Click the checkbox** to mark a task done
|
||||
- Completed tasks move to the "Completed" tab
|
||||
- Feel the satisfaction! ✓
|
||||
### Execution Modes
|
||||
|
||||
### Filter Tabs
|
||||
| Mode | Best For |
|
||||
|------|----------|
|
||||
| **Semi-Automatic** | Most tasks - automatic with safety pauses |
|
||||
| **Supervised** | Learning or sensitive operations |
|
||||
| **Fully Automatic** | Trusted, tested workflows |
|
||||
| **Dry Run** | Testing before real execution |
|
||||
|
||||
| Tab | Shows |
|
||||
|-----|-------|
|
||||
| **All** | Everything |
|
||||
| **Active** | Tasks not yet done |
|
||||
| **Completed** | Finished tasks |
|
||||
| **Priority** | High-priority tasks only |
|
||||
### Monitoring Tasks
|
||||
|
||||
- **Running** - Currently executing (shows progress bar)
|
||||
- **Pending Approval** - Waiting for you to approve a high-risk step
|
||||
- **Waiting Decision** - Needs your input to continue
|
||||
- **Completed** - Successfully finished
|
||||
|
||||
### Approvals & Decisions
|
||||
|
||||
High-impact actions pause for your approval:
|
||||
- Sending mass emails
|
||||
- Modifying databases
|
||||
- Deploying to production
|
||||
- Actions exceeding cost thresholds
|
||||
|
||||
Click **✅ Review & Approve** to see details and continue.
|
||||
|
||||
### Creating Tasks from Chat
|
||||
|
||||
In Chat, just say:
|
||||
```
|
||||
You: Create a task to review the budget by Friday
|
||||
Bot: Task created: "Review the budget" - Due: Friday
|
||||
You: I need to build a customer portal for Acme Corp
|
||||
Bot: I'll create an Task for that. Here's the plan:
|
||||
- 5 steps, estimated 3 hours
|
||||
- Risk: Low
|
||||
Should I execute this plan?
|
||||
You: Yes, go ahead
|
||||
Bot: 🚀 Task started!
|
||||
```
|
||||
|
||||
---
|
||||
|
|
|
|||
|
|
@ -1,6 +1,6 @@
|
|||
# UI Structure
|
||||
|
||||
The BotServer UI system provides two interface implementations designed for different deployment scenarios. Choose the right interface based on your use case and performance requirements.
|
||||
The botserver UI system provides two interface implementations designed for different deployment scenarios. Choose the right interface based on your use case and performance requirements.
|
||||
|
||||
<img src="../assets/gb-decorative-header.svg" alt="General Bots" style="max-height: 100px; width: 100%; object-fit: contain;">
|
||||
|
||||
|
|
|
|||
|
|
@ -211,7 +211,7 @@ BASIC provides built-in capabilities for common office tasks:
|
|||
|
||||
### Quick Start
|
||||
|
||||
1. Download and run BotServer
|
||||
1. Download and run botserver
|
||||
2. Edit your bot's `.bas` files
|
||||
3. Configure settings in `config.csv`
|
||||
4. Deploy to any channel
|
||||
|
|
|
|||
|
|
@ -1,34 +1,433 @@
|
|||
# CREATE SITE Keyword
|
||||
|
||||
**Syntax**
|
||||
> **Generate Complete HTMX Web Applications Autonomously**
|
||||
|
||||
```
|
||||
---
|
||||
|
||||
## Overview
|
||||
|
||||
`CREATE SITE` is the cornerstone keyword for autonomous app generation in General Bots. It transforms natural language descriptions into fully functional HTMX-based web applications that are automatically bound to the botserver API.
|
||||
|
||||
**The key insight:** Generated apps don't need their own backend - they use botserver's infrastructure through HTMX calls.
|
||||
|
||||
---
|
||||
|
||||
## Syntax
|
||||
|
||||
```basic
|
||||
CREATE SITE "alias", "template-dir", "prompt"
|
||||
```
|
||||
|
||||
**Parameters**
|
||||
**Parameters:**
|
||||
|
||||
- `"alias"` – Name of the new site (used as a folder name under the configured site path).
|
||||
- `"template-dir"` – Relative path to a directory containing HTML template files that will be combined.
|
||||
- `"prompt"` – Text prompt sent to the LLM to generate the final site content.
|
||||
| Parameter | Description |
|
||||
|-----------|-------------|
|
||||
| `alias` | Name of the new site (becomes URL endpoint and folder name) |
|
||||
| `template-dir` | Path to HTML templates that serve as reference |
|
||||
| `prompt` | Natural language description of what to build |
|
||||
|
||||
**Description**
|
||||
---
|
||||
|
||||
`CREATE SITE` generates a new static website based on existing HTML templates and an LLM‑generated prompt. The keyword performs the following steps:
|
||||
## How It Works
|
||||
|
||||
1. Creates a directory for the new site at `<site_path>/<alias>`.
|
||||
2. Reads all `.html` files from `<site_path>/<template-dir>` and concatenates their contents, separating each with a clear delimiter.
|
||||
3. Constructs a prompt that includes the combined template content and the user‑provided `prompt`.
|
||||
4. Sends the prompt to the configured LLM provider (`utils::call_llm`) and receives generated HTML.
|
||||
5. Writes the LLM output to `<site_path>/<alias>/index.html`.
|
||||
### 1. Template Loading
|
||||
|
||||
The resulting site can be served directly from the `site_path` directory. Errors during directory creation, file reading, or LLM generation are logged and returned as error messages.
|
||||
The system reads all `.html` files from the template directory:
|
||||
|
||||
**Example**
|
||||
|
||||
```basic
|
||||
CREATE SITE "my_blog", "templates/blog", "Generate a modern blog homepage for a tech writer."
|
||||
TALK "Site created at /my_blog. Access it via the web server."
|
||||
```
|
||||
templates/app/
|
||||
├── layout.html # Page structure
|
||||
├── components.html # Reusable UI components
|
||||
├── forms.html # Form patterns
|
||||
└── data-table.html # List/table patterns
|
||||
```
|
||||
|
||||
After execution, a folder `my_blog` is created with an `index.html` containing the LLM‑generated page, ready to be served.
|
||||
All templates are combined with separators to give the LLM context about available patterns.
|
||||
|
||||
### 2. LLM Generation
|
||||
|
||||
The combined templates + prompt are sent to the LLM with instructions to:
|
||||
|
||||
- Clone the template structure and styling
|
||||
- Use only local `_assets` (no external CDNs)
|
||||
- Bind all data operations to botserver API via HTMX
|
||||
- Generate semantic, accessible HTML
|
||||
|
||||
### 3. Deployment
|
||||
|
||||
The generated `index.html` is written to `<site_path>/<alias>/`:
|
||||
|
||||
```
|
||||
sites/
|
||||
└── crm/
|
||||
├── index.html # Generated application
|
||||
└── _assets/ # Copied from templates
|
||||
├── htmx.min.js
|
||||
├── app.js
|
||||
└── styles.css
|
||||
```
|
||||
|
||||
The site is immediately available at `/<alias>` endpoint.
|
||||
|
||||
---
|
||||
|
||||
## Generated HTMX Patterns
|
||||
|
||||
### Data Lists with Auto-Refresh
|
||||
|
||||
```html
|
||||
<!-- Lead list that loads on page and refreshes every 30s -->
|
||||
<div id="leads"
|
||||
hx-get="/api/data/leads"
|
||||
hx-trigger="load, every 30s"
|
||||
hx-swap="innerHTML">
|
||||
<div class="loading">Loading leads...</div>
|
||||
</div>
|
||||
```
|
||||
|
||||
### Create Forms
|
||||
|
||||
```html
|
||||
<form hx-post="/api/data/leads"
|
||||
hx-target="#leads"
|
||||
hx-swap="afterbegin"
|
||||
hx-indicator="#saving">
|
||||
<input name="name" placeholder="Lead name" required>
|
||||
<input name="email" type="email" placeholder="Email">
|
||||
<input name="phone" placeholder="Phone">
|
||||
<select name="status">
|
||||
<option value="new">New</option>
|
||||
<option value="contacted">Contacted</option>
|
||||
<option value="qualified">Qualified</option>
|
||||
</select>
|
||||
<button type="submit">
|
||||
<span class="btn-text">Add Lead</span>
|
||||
<span id="saving" class="htmx-indicator">Saving...</span>
|
||||
</button>
|
||||
</form>
|
||||
```
|
||||
|
||||
### Inline Editing
|
||||
|
||||
```html
|
||||
<div class="lead-card"
|
||||
hx-get="/api/data/leads/${id}"
|
||||
hx-trigger="click"
|
||||
hx-target="#detail-panel"
|
||||
hx-swap="innerHTML">
|
||||
<h3>${name}</h3>
|
||||
<p>${email}</p>
|
||||
<span class="status status-${status}">${status}</span>
|
||||
</div>
|
||||
```
|
||||
|
||||
### Delete with Confirmation
|
||||
|
||||
```html
|
||||
<button hx-delete="/api/data/leads/${id}"
|
||||
hx-target="closest .lead-card"
|
||||
hx-swap="outerHTML swap:1s"
|
||||
hx-confirm="Delete this lead?">
|
||||
🗑️ Delete
|
||||
</button>
|
||||
```
|
||||
|
||||
### Search and Filter
|
||||
|
||||
```html
|
||||
<input type="search"
|
||||
name="q"
|
||||
placeholder="Search leads..."
|
||||
hx-get="/api/data/leads"
|
||||
hx-trigger="keyup changed delay:300ms"
|
||||
hx-target="#leads"
|
||||
hx-include="[name='status-filter']">
|
||||
|
||||
<select name="status-filter"
|
||||
hx-get="/api/data/leads"
|
||||
hx-trigger="change"
|
||||
hx-target="#leads"
|
||||
hx-include="[name='q']">
|
||||
<option value="">All Statuses</option>
|
||||
<option value="new">New</option>
|
||||
<option value="contacted">Contacted</option>
|
||||
</select>
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## API Binding
|
||||
|
||||
Generated HTMX calls map directly to botserver endpoints:
|
||||
|
||||
| HTMX Attribute | Endpoint | BASIC Equivalent |
|
||||
|----------------|----------|------------------|
|
||||
| `hx-get="/api/data/{table}"` | List/Read | `FIND "{table}"` |
|
||||
| `hx-post="/api/data/{table}"` | Create | `UPSERT "{table}"` |
|
||||
| `hx-put="/api/data/{table}/{id}"` | Update | `SET "{table}"` |
|
||||
| `hx-delete="/api/data/{table}/{id}"` | Delete | `DELETE "{table}"` |
|
||||
|
||||
### Query Parameters
|
||||
|
||||
The API supports filtering via query params:
|
||||
|
||||
```html
|
||||
<!-- Filter by status -->
|
||||
hx-get="/api/data/leads?status=new"
|
||||
|
||||
<!-- Sort by date -->
|
||||
hx-get="/api/data/leads?sort=created_at&order=desc"
|
||||
|
||||
<!-- Pagination -->
|
||||
hx-get="/api/data/leads?page=2&limit=20"
|
||||
|
||||
<!-- Search -->
|
||||
hx-get="/api/data/leads?q=john"
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## JavaScript Integration
|
||||
|
||||
Generated apps include `app.js` for interactions that need JavaScript:
|
||||
|
||||
```javascript
|
||||
// Toast notifications
|
||||
function showToast(message, type = 'success') {
|
||||
const toast = document.createElement('div');
|
||||
toast.className = `toast toast-${type}`;
|
||||
toast.textContent = message;
|
||||
document.body.appendChild(toast);
|
||||
setTimeout(() => toast.remove(), 3000);
|
||||
}
|
||||
|
||||
// HTMX event hooks
|
||||
document.body.addEventListener('htmx:afterSwap', (e) => {
|
||||
if (e.detail.target.id === 'leads') {
|
||||
showToast('Data updated');
|
||||
}
|
||||
});
|
||||
|
||||
document.body.addEventListener('htmx:responseError', (e) => {
|
||||
showToast('Error: ' + e.detail.error, 'error');
|
||||
});
|
||||
|
||||
// Modal handling
|
||||
function openModal(id) {
|
||||
document.getElementById(id).classList.add('active');
|
||||
}
|
||||
|
||||
function closeModal(id) {
|
||||
document.getElementById(id).classList.remove('active');
|
||||
}
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Examples
|
||||
|
||||
### Simple CRM
|
||||
|
||||
```basic
|
||||
CREATE SITE "crm", "bottemplates/apps/crud", "
|
||||
Build a CRM with:
|
||||
- Contact list with search and filters
|
||||
- Add/edit contact form (name, email, phone, company)
|
||||
- Status tracking (lead, prospect, customer)
|
||||
- Activity timeline per contact
|
||||
- Quick action buttons (call, email)
|
||||
"
|
||||
```
|
||||
|
||||
### Dashboard
|
||||
|
||||
```basic
|
||||
CREATE SITE "dashboard", "bottemplates/apps/dashboard", "
|
||||
Create an executive dashboard showing:
|
||||
- KPI cards (revenue, customers, orders, growth)
|
||||
- Revenue chart (last 12 months)
|
||||
- Top products table
|
||||
- Recent orders list
|
||||
- Auto-refresh every 60 seconds
|
||||
"
|
||||
```
|
||||
|
||||
### Project Tracker
|
||||
|
||||
```basic
|
||||
CREATE SITE "projects", "bottemplates/apps/kanban", "
|
||||
Build a project management board with:
|
||||
- Kanban columns (Backlog, In Progress, Review, Done)
|
||||
- Drag and drop cards between columns
|
||||
- Card details (title, description, assignee, due date)
|
||||
- Filter by assignee or status
|
||||
- Quick add card form
|
||||
"
|
||||
```
|
||||
|
||||
### E-commerce Admin
|
||||
|
||||
```basic
|
||||
CREATE SITE "shop-admin", "bottemplates/apps/admin", "
|
||||
Create an admin panel for e-commerce:
|
||||
- Products table with inline editing
|
||||
- Order management with status updates
|
||||
- Customer list with order history
|
||||
- Inventory alerts (low stock)
|
||||
- Sales summary charts
|
||||
"
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Template Structure
|
||||
|
||||
Organize templates for reuse:
|
||||
|
||||
```
|
||||
bottemplates/apps/
|
||||
├── crud/ # CRUD application templates
|
||||
│ ├── layout.html # Base page structure
|
||||
│ ├── data-row.html # Table row template
|
||||
│ └── form-modal.html # Modal form pattern
|
||||
├── dashboard/ # Dashboard templates
|
||||
│ ├── layout.html # Dashboard layout
|
||||
│ ├── kpi-card.html # Metric card
|
||||
│ └── chart.html # Chart container
|
||||
├── kanban/ # Board templates
|
||||
│ ├── layout.html # Kanban layout
|
||||
│ ├── column.html # Single column
|
||||
│ └── card.html # Task card
|
||||
├── admin/ # Admin panel templates
|
||||
│ ├── layout.html # Admin structure
|
||||
│ └── sidebar.html # Navigation
|
||||
└── components/ # Reusable components
|
||||
├── data-table.html # Sortable table
|
||||
├── search-filter.html # Search with filters
|
||||
└── toast.html # Notifications
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Styling
|
||||
|
||||
Generated apps use CSS variables for theming:
|
||||
|
||||
```css
|
||||
:root {
|
||||
--color-primary: #0ea5e9;
|
||||
--color-success: #10b981;
|
||||
--color-warning: #f59e0b;
|
||||
--color-danger: #ef4444;
|
||||
--color-bg: #ffffff;
|
||||
--color-text: #1e293b;
|
||||
--color-border: #e2e8f0;
|
||||
--radius: 8px;
|
||||
--shadow: 0 1px 3px rgba(0,0,0,0.1);
|
||||
}
|
||||
|
||||
@media (prefers-color-scheme: dark) {
|
||||
:root {
|
||||
--color-bg: #0f172a;
|
||||
--color-text: #f1f5f9;
|
||||
--color-border: #334155;
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Storage
|
||||
|
||||
Generated sites and their data live in `.gbdrive`:
|
||||
|
||||
```
|
||||
project.gbdrive/
|
||||
├── apps/
|
||||
│ └── crm/
|
||||
│ ├── index.html # Generated app
|
||||
│ └── _assets/ # Static files
|
||||
├── data/
|
||||
│ └── contacts.json # App data
|
||||
└── uploads/
|
||||
└── ... # User uploads
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Error Handling
|
||||
|
||||
Generated apps handle errors gracefully:
|
||||
|
||||
```html
|
||||
<!-- Loading state -->
|
||||
<div class="htmx-indicator">
|
||||
<span class="spinner"></span> Loading...
|
||||
</div>
|
||||
|
||||
<!-- Error display -->
|
||||
<div id="error-container"
|
||||
hx-swap-oob="true"
|
||||
class="error-message">
|
||||
</div>
|
||||
```
|
||||
|
||||
```javascript
|
||||
// Global error handler
|
||||
document.body.addEventListener('htmx:responseError', function(e) {
|
||||
document.getElementById('error-container').innerHTML =
|
||||
`<div class="alert alert-error">
|
||||
${e.detail.xhr.responseText || 'An error occurred'}
|
||||
</div>`;
|
||||
});
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Best Practices
|
||||
|
||||
### Be Specific in Prompts
|
||||
|
||||
✅ **Good:**
|
||||
```basic
|
||||
CREATE SITE "crm", "bottemplates/apps/crud", "
|
||||
Build a real estate CRM with:
|
||||
- Lead list showing name, phone, property interest, status
|
||||
- Filter by status (new, contacted, showing, offer, closed)
|
||||
- Add lead form with validation
|
||||
- Click lead to see full details and notes
|
||||
- Add note button on detail view
|
||||
"
|
||||
```
|
||||
|
||||
❌ **Bad:**
|
||||
```basic
|
||||
CREATE SITE "crm", "templates/app", "Make a CRM"
|
||||
```
|
||||
|
||||
### Use Appropriate Templates
|
||||
|
||||
Match your template to the use case:
|
||||
- `bottemplates/apps/crud` - General CRUD applications
|
||||
- `bottemplates/apps/dashboard` - Dashboards and reports
|
||||
- `bottemplates/apps/kanban` - Board-style interfaces
|
||||
- `bottemplates/apps/admin` - Admin panels
|
||||
|
||||
### Test with Dry Run
|
||||
|
||||
Use autonomous task dry run mode to preview before deploying:
|
||||
|
||||
```basic
|
||||
' In supervised/dry-run mode
|
||||
CREATE SITE "test-crm", "bottemplates/apps/crud", "..."
|
||||
' Review generated HTML before committing
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## See Also
|
||||
|
||||
- [Autonomous Task AI](../07-gbapp/autonomous-tasks.md) - How the machine does the work
|
||||
- [HTMX Architecture](../04-gbui/htmx-architecture.md) - UI patterns
|
||||
- [.gbdrive Storage](../02-templates/gbdrive.md) - File management
|
||||
- [API Reference](../10-rest/README.md) - botserver endpoints
|
||||
275
src/06-gbdialog/keyword-goto.md
Normal file
275
src/06-gbdialog/keyword-goto.md
Normal file
|
|
@ -0,0 +1,275 @@
|
|||
# GOTO Keyword
|
||||
|
||||
> ⚠️ **WARNING: GOTO is supported but NOT RECOMMENDED**
|
||||
>
|
||||
> While GOTO works for backward compatibility, you should use **event-driven patterns with the ON keyword** instead. GOTO makes code harder to maintain and debug.
|
||||
|
||||
## Syntax
|
||||
|
||||
```basic
|
||||
label:
|
||||
' statements
|
||||
GOTO label
|
||||
|
||||
IF condition THEN GOTO label
|
||||
```
|
||||
|
||||
## Description
|
||||
|
||||
`GOTO` transfers program execution to a labeled line. Labels are identifiers followed by a colon (`:`) at the start of a line.
|
||||
|
||||
**This keyword exists for backward compatibility only.** Modern General Bots code should use:
|
||||
|
||||
- `ON INSERT/UPDATE/DELETE OF` for event-driven programming
|
||||
- `WHILE ... WEND` for loops
|
||||
- `FOR EACH ... NEXT` for iteration
|
||||
- `SUB` / `FUNCTION` for code organization
|
||||
|
||||
---
|
||||
|
||||
## ❌ OLD WAY vs ✅ NEW WAY
|
||||
|
||||
### Polling Loop (Don't Do This)
|
||||
|
||||
```basic
|
||||
' ❌ BAD: GOTO-based polling loop
|
||||
mainLoop:
|
||||
leads = FIND "leads", "processed = false"
|
||||
FOR EACH lead IN leads
|
||||
CALL processLead(lead)
|
||||
NEXT lead
|
||||
WAIT 5
|
||||
GOTO mainLoop
|
||||
```
|
||||
|
||||
### Event-Driven (Do This Instead)
|
||||
|
||||
```basic
|
||||
' ✅ GOOD: Event-driven with ON keyword
|
||||
ON INSERT OF "leads"
|
||||
lead = GET LAST "leads"
|
||||
|
||||
score = SCORE LEAD lead
|
||||
|
||||
IF score.status = "hot" THEN
|
||||
TALK TO "whatsapp:" + sales_phone, "🔥 Hot lead: " + lead.name
|
||||
END IF
|
||||
END ON
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Why ON is Better Than GOTO
|
||||
|
||||
| Aspect | GOTO Loop | ON Event |
|
||||
|--------|-----------|----------|
|
||||
| **Efficiency** | Polls constantly, wastes CPU | Triggers only when data changes |
|
||||
| **Code clarity** | Spaghetti code, hard to follow | Clear cause-and-effect |
|
||||
| **Resource usage** | Always running | Idle until triggered |
|
||||
| **Scalability** | Degrades with more data | Handles scale naturally |
|
||||
| **Debugging** | Hard to trace execution | Clear event flow |
|
||||
| **LLM integration** | Poor | Works well with TOOLs |
|
||||
|
||||
---
|
||||
|
||||
## If You Must Use GOTO
|
||||
|
||||
For legacy code migration or specific use cases, GOTO is supported:
|
||||
|
||||
### Simple Loop
|
||||
|
||||
```basic
|
||||
counter:
|
||||
TALK "Count: " + x
|
||||
x = x + 1
|
||||
IF x < 5 THEN GOTO counter
|
||||
TALK "Done!"
|
||||
```
|
||||
|
||||
### Multiple Labels
|
||||
|
||||
```basic
|
||||
start:
|
||||
TALK "Starting..."
|
||||
GOTO process
|
||||
|
||||
error:
|
||||
TALK "An error occurred"
|
||||
GOTO cleanup
|
||||
|
||||
process:
|
||||
result = DO_SOMETHING
|
||||
IF result = "error" THEN GOTO error
|
||||
TALK "Success!"
|
||||
GOTO cleanup
|
||||
|
||||
cleanup:
|
||||
TALK "Cleaning up..."
|
||||
```
|
||||
|
||||
### Conditional GOTO
|
||||
|
||||
```basic
|
||||
check:
|
||||
IF temperature > 30 THEN GOTO too_hot
|
||||
IF temperature < 10 THEN GOTO too_cold
|
||||
TALK "Temperature is comfortable"
|
||||
GOTO done
|
||||
|
||||
too_hot:
|
||||
TALK "Warning: Too hot!"
|
||||
GPIO SET fan_pin, HIGH
|
||||
GOTO done
|
||||
|
||||
too_cold:
|
||||
TALK "Warning: Too cold!"
|
||||
GPIO SET heater_pin, HIGH
|
||||
GOTO done
|
||||
|
||||
done:
|
||||
TALK "Check complete"
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## How GOTO Works Internally
|
||||
|
||||
GOTO is **not native to the Rhai engine**. General Bots transforms GOTO-based code into a state machine:
|
||||
|
||||
```basic
|
||||
' Your code:
|
||||
loop:
|
||||
x = x + 1
|
||||
IF x < 3 THEN GOTO loop
|
||||
TALK "Done"
|
||||
```
|
||||
|
||||
```basic
|
||||
' Transformed internally to:
|
||||
let __goto_label = "loop"
|
||||
while __goto_label != "__exit" {
|
||||
if __goto_label == "loop" {
|
||||
x = x + 1
|
||||
if x < 3 { __goto_label = "loop"; continue; }
|
||||
TALK "Done"
|
||||
__goto_label = "__exit"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
This transformation:
|
||||
- Adds overhead compared to native loops
|
||||
- Has a safety limit of 1,000,000 iterations to prevent infinite loops
|
||||
- Emits warnings in the server logs recommending ON patterns
|
||||
|
||||
---
|
||||
|
||||
## Limitations
|
||||
|
||||
| Limitation | Description |
|
||||
|------------|-------------|
|
||||
| **No computed GOTO** | `GOTO variable` is not supported |
|
||||
| **No GOSUB** | Use `SUB` / `CALL` instead |
|
||||
| **No line numbers** | Only named labels are supported |
|
||||
| **Performance** | Slower than native WHILE loops |
|
||||
| **Iteration limit** | Maximum 1,000,000 iterations per GOTO loop |
|
||||
|
||||
---
|
||||
|
||||
## Migration Guide
|
||||
|
||||
### From GOTO Loop to WHILE
|
||||
|
||||
```basic
|
||||
' Before (GOTO):
|
||||
start:
|
||||
TALK "Hello"
|
||||
x = x + 1
|
||||
IF x < 10 THEN GOTO start
|
||||
|
||||
' After (WHILE):
|
||||
WHILE x < 10
|
||||
TALK "Hello"
|
||||
x = x + 1
|
||||
WEND
|
||||
```
|
||||
|
||||
### From GOTO Loop to ON Event
|
||||
|
||||
```basic
|
||||
' Before (GOTO polling):
|
||||
checkOrders:
|
||||
orders = FIND "orders", "status = 'new'"
|
||||
FOR EACH order IN orders
|
||||
CALL processOrder(order)
|
||||
NEXT order
|
||||
WAIT 10
|
||||
GOTO checkOrders
|
||||
|
||||
' After (ON event):
|
||||
ON INSERT OF "orders"
|
||||
order = GET LAST "orders"
|
||||
IF order.status = "new" THEN
|
||||
CALL processOrder(order)
|
||||
END IF
|
||||
END ON
|
||||
```
|
||||
|
||||
### From GOTO Error Handling to ON ERROR
|
||||
|
||||
```basic
|
||||
' Before (GOTO):
|
||||
result = RISKY_OPERATION
|
||||
IF result = "error" THEN GOTO handleError
|
||||
TALK "Success"
|
||||
GOTO done
|
||||
handleError:
|
||||
TALK "Failed!"
|
||||
done:
|
||||
|
||||
' After (ON ERROR):
|
||||
ON ERROR RESUME NEXT
|
||||
result = RISKY_OPERATION
|
||||
IF ERROR THEN
|
||||
TALK "Failed!"
|
||||
ELSE
|
||||
TALK "Success"
|
||||
END IF
|
||||
ON ERROR GOTO 0
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Best Practices
|
||||
|
||||
1. **Don't use GOTO for new code** - Use WHILE, FOR EACH, ON, or SUB/FUNCTION
|
||||
2. **Migrate existing GOTO code** - Refactor to event-driven patterns when possible
|
||||
3. **If you must use GOTO** - Keep it simple, avoid deep nesting
|
||||
4. **Add comments** - Explain why GOTO is necessary
|
||||
5. **Set reasonable limits** - Don't rely on the 1M iteration safety limit
|
||||
|
||||
---
|
||||
|
||||
## See Also
|
||||
|
||||
- [ON Keyword](./keyword-on.md) - **Recommended**: Event-driven programming
|
||||
- [WHILE ... WEND](./keyword-while.md) - Loop construct
|
||||
- [FOR EACH ... NEXT](./keyword-for-each.md) - Iteration
|
||||
- [SUB / FUNCTION](./keyword-sub.md) - Code organization
|
||||
- [ON ERROR](./keyword-on-error.md) - Error handling
|
||||
|
||||
---
|
||||
|
||||
## Summary
|
||||
|
||||
| Use Case | Instead of GOTO, Use |
|
||||
|----------|---------------------|
|
||||
| Polling for changes | `ON INSERT/UPDATE/DELETE OF` |
|
||||
| Repeating code | `WHILE ... WEND` |
|
||||
| Iterating collections | `FOR EACH ... NEXT` |
|
||||
| Reusable code blocks | `SUB` / `FUNCTION` + `CALL` |
|
||||
| Error handling | `ON ERROR RESUME NEXT` |
|
||||
| Conditional branching | `IF ... ELSEIF ... ELSE ... END IF` |
|
||||
| Multiple conditions | `SWITCH ... CASE ... END SWITCH` |
|
||||
|
||||
**The ON keyword is the future. GOTO is the past.**
|
||||
345
src/06-gbdialog/keyword-use-mcp.md
Normal file
345
src/06-gbdialog/keyword-use-mcp.md
Normal file
|
|
@ -0,0 +1,345 @@
|
|||
# USE MCP
|
||||
|
||||
> **Invoke MCP Server Tools from BASIC**
|
||||
|
||||
---
|
||||
|
||||
## Overview
|
||||
|
||||
The `USE MCP` keyword allows you to invoke tools from Model Context Protocol (MCP) servers directly in your BASIC scripts. MCP servers extend your bot's capabilities by providing access to external systems like databases, filesystems, APIs, and more.
|
||||
|
||||
---
|
||||
|
||||
## Syntax
|
||||
|
||||
```bas
|
||||
result = USE MCP "server_name", "tool_name", {parameters}
|
||||
```
|
||||
|
||||
| Parameter | Description |
|
||||
|-----------|-------------|
|
||||
| `server_name` | Name of the MCP server (as defined in `mcp.csv`) |
|
||||
| `tool_name` | Name of the tool to invoke |
|
||||
| `parameters` | JSON object with tool parameters |
|
||||
|
||||
---
|
||||
|
||||
## The mcp.csv File
|
||||
|
||||
MCP servers are configured by adding entries to the `mcp.csv` file in your bot's `.gbai` folder:
|
||||
|
||||
```
|
||||
mybot.gbai/
|
||||
├── mybot.gbdialog/ # BASIC scripts
|
||||
├── mybot.gbdrive/ # Files and documents
|
||||
├── config.csv # Bot configuration
|
||||
├── attendant.csv # Attendant configuration
|
||||
└── mcp.csv # MCP server definitions
|
||||
```
|
||||
|
||||
When botserver starts, it reads the `mcp.csv` file and loads all server configurations. These servers become available to Tasks and can be invoked using the `USE MCP` keyword.
|
||||
|
||||
---
|
||||
|
||||
## mcp.csv Format
|
||||
|
||||
The CSV file has the following columns:
|
||||
|
||||
| Column | Required | Description |
|
||||
|--------|----------|-------------|
|
||||
| `name` | Yes | Unique server identifier (used in `USE MCP` calls) |
|
||||
| `type` | Yes | Connection type: `stdio`, `http`, `websocket`, `tcp` |
|
||||
| `command` | Yes | For stdio: command to run. For http/ws: URL |
|
||||
| `args` | No | Command arguments (space-separated) or empty |
|
||||
| `description` | No | Human-readable description |
|
||||
| `enabled` | No | `true` or `false` (default: `true`) |
|
||||
| `auth_type` | No | Authentication type: `none`, `api_key`, `bearer` |
|
||||
| `auth_env` | No | Environment variable name for auth credential |
|
||||
| `risk_level` | No | `safe`, `low`, `medium`, `high`, `critical` |
|
||||
| `requires_approval` | No | `true` or `false` (default: `false`) |
|
||||
|
||||
### Example mcp.csv
|
||||
|
||||
```csv
|
||||
name,type,command,args,description,enabled
|
||||
# MCP Server Configuration
|
||||
# Lines starting with # are comments
|
||||
filesystem,stdio,npx,"-y @modelcontextprotocol/server-filesystem /data",Access local files,true
|
||||
github,stdio,npx,"-y @modelcontextprotocol/server-github",GitHub API,true,bearer,GITHUB_TOKEN
|
||||
postgres,stdio,npx,"-y @modelcontextprotocol/server-postgres",Database queries,false
|
||||
slack,stdio,npx,"-y @modelcontextprotocol/server-slack",Slack messaging,true,bearer,SLACK_BOT_TOKEN
|
||||
myapi,http,https://api.example.com/mcp,,Custom API,true,api_key,MY_API_KEY
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Connection Types
|
||||
|
||||
### stdio (Local Process)
|
||||
|
||||
For MCP servers that run as local processes via npx, node, python, etc:
|
||||
|
||||
```csv
|
||||
filesystem,stdio,npx,"-y @modelcontextprotocol/server-filesystem /data",File access,true
|
||||
```
|
||||
|
||||
The `command` is the executable, and `args` contains the arguments.
|
||||
|
||||
### http (REST API)
|
||||
|
||||
For HTTP-based MCP servers:
|
||||
|
||||
```csv
|
||||
myapi,http,https://api.example.com/mcp,,REST API server,true
|
||||
```
|
||||
|
||||
The `command` is the URL endpoint.
|
||||
|
||||
### websocket
|
||||
|
||||
For WebSocket connections:
|
||||
|
||||
```csv
|
||||
realtime,websocket,wss://ws.example.com/mcp,,Real-time server,true
|
||||
```
|
||||
|
||||
### tcp
|
||||
|
||||
For raw TCP connections:
|
||||
|
||||
```csv
|
||||
legacy,tcp,localhost:9000,,Legacy TCP server,true
|
||||
```
|
||||
|
||||
Format: `host:port` in the command column.
|
||||
|
||||
---
|
||||
|
||||
## Authentication
|
||||
|
||||
### API Key
|
||||
|
||||
```csv
|
||||
myapi,http,https://api.example.com,,API Server,true,api_key,MY_API_KEY
|
||||
```
|
||||
|
||||
The environment variable `MY_API_KEY` will be read and sent as `X-API-Key` header.
|
||||
|
||||
### Bearer Token
|
||||
|
||||
```csv
|
||||
github,stdio,npx,"-y @modelcontextprotocol/server-github",GitHub,true,bearer,GITHUB_TOKEN
|
||||
```
|
||||
|
||||
The environment variable `GITHUB_TOKEN` will be used as a Bearer token.
|
||||
|
||||
> **Security**: Authentication credentials are read from environment variables. Never put actual secrets in mcp.csv.
|
||||
|
||||
---
|
||||
|
||||
## Examples
|
||||
|
||||
### Read a File
|
||||
|
||||
```bas
|
||||
' Read a file using filesystem MCP server
|
||||
content = USE MCP "filesystem", "read_file", {"path": "/data/config.json"}
|
||||
TALK "File contents: " + content
|
||||
```
|
||||
|
||||
### Query Database
|
||||
|
||||
```bas
|
||||
' Query PostgreSQL using database MCP server
|
||||
results = USE MCP "postgres", "query", {"sql": "SELECT * FROM users LIMIT 10"}
|
||||
FOR EACH row IN results
|
||||
TALK row.name + " - " + row.email
|
||||
NEXT
|
||||
```
|
||||
|
||||
### Search GitHub
|
||||
|
||||
```bas
|
||||
' Search GitHub repositories
|
||||
repos = USE MCP "github", "search_repositories", {"query": "general bots language:rust"}
|
||||
TALK "Found " + repos.length + " repositories"
|
||||
```
|
||||
|
||||
### Send Slack Message
|
||||
|
||||
```bas
|
||||
' Send message to Slack channel
|
||||
USE MCP "slack", "send_message", {
|
||||
"channel": "#general",
|
||||
"text": "Hello from General Bots!"
|
||||
}
|
||||
```
|
||||
|
||||
### Create GitHub Issue
|
||||
|
||||
```bas
|
||||
' Create an issue (requires approval if configured)
|
||||
issue = USE MCP "github", "create_issue", {
|
||||
"owner": "myorg",
|
||||
"repo": "myproject",
|
||||
"title": "Bug: Login not working",
|
||||
"body": "Users cannot log in with SSO"
|
||||
}
|
||||
TALK "Created issue #" + issue.number
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Related Keywords
|
||||
|
||||
### MCP LIST TOOLS
|
||||
|
||||
List available tools from an MCP server:
|
||||
|
||||
```bas
|
||||
tools = MCP LIST TOOLS "filesystem"
|
||||
FOR EACH tool IN tools
|
||||
TALK tool.name + ": " + tool.description
|
||||
NEXT
|
||||
```
|
||||
|
||||
### MCP INVOKE
|
||||
|
||||
Alternative syntax for direct tool invocation:
|
||||
|
||||
```bas
|
||||
result = MCP INVOKE "filesystem.read_file", {"path": "/data/file.txt"}
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Risk Levels
|
||||
|
||||
Tools have risk levels that determine how they're handled:
|
||||
|
||||
| Level | Description | Behavior |
|
||||
|-------|-------------|----------|
|
||||
| **safe** | Read-only, no side effects | Always allowed |
|
||||
| **low** | Minor changes, reversible | Usually allowed |
|
||||
| **medium** | Significant changes | May require approval |
|
||||
| **high** | Destructive or irreversible | Requires approval |
|
||||
| **critical** | System-level changes | Always requires approval |
|
||||
|
||||
When `requires_approval` is set to `true`, the task will pause and wait for human approval before executing the tool.
|
||||
|
||||
---
|
||||
|
||||
## Tool Discovery
|
||||
|
||||
MCP tools are discovered automatically when the server starts. You can see available tools in:
|
||||
|
||||
1. **Sources UI** → MCP Servers tab → View Tools
|
||||
2. **Sources UI** → LLM Tools tab → MCP Tools section
|
||||
3. **BASIC** → `MCP LIST TOOLS "server_name"`
|
||||
|
||||
---
|
||||
|
||||
## Available MCP Servers
|
||||
|
||||
Popular MCP servers you can use:
|
||||
|
||||
| Server | Package | Description |
|
||||
|--------|---------|-------------|
|
||||
| **Filesystem** | `@modelcontextprotocol/server-filesystem` | File operations |
|
||||
| **GitHub** | `@modelcontextprotocol/server-github` | GitHub API |
|
||||
| **PostgreSQL** | `@modelcontextprotocol/server-postgres` | Database queries |
|
||||
| **SQLite** | `@modelcontextprotocol/server-sqlite` | SQLite database |
|
||||
| **Slack** | `@modelcontextprotocol/server-slack` | Slack messaging |
|
||||
| **Puppeteer** | `@modelcontextprotocol/server-puppeteer` | Browser automation |
|
||||
| **Brave Search** | `@modelcontextprotocol/server-brave-search` | Web search |
|
||||
|
||||
See [modelcontextprotocol.io](https://modelcontextprotocol.io) for more servers.
|
||||
|
||||
---
|
||||
|
||||
## Integration with Tasks
|
||||
|
||||
When you add MCP servers to your bot via `mcp.csv`, their tools become available to the Autonomous Task system. The AI can:
|
||||
|
||||
1. **Discover tools** from your MCP servers
|
||||
2. **Plan execution** using MCP tools alongside BASIC keywords
|
||||
3. **Request approval** for high-risk operations
|
||||
4. **Execute tools** and process results
|
||||
|
||||
Example task flow:
|
||||
|
||||
```
|
||||
User: "Read the config file and update the database accordingly"
|
||||
|
||||
AI Plan:
|
||||
1. USE MCP "filesystem", "read_file" → Read config.json
|
||||
2. Parse JSON configuration
|
||||
3. USE MCP "postgres", "query" → Update database
|
||||
4. Report results
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Troubleshooting
|
||||
|
||||
### Server Not Found
|
||||
|
||||
```
|
||||
Error: MCP server 'myserver' not found
|
||||
```
|
||||
|
||||
- Check that `mcp.csv` exists in your `.gbai` folder
|
||||
- Verify the server name matches exactly (case-sensitive)
|
||||
- Ensure `enabled` is not set to `false`
|
||||
- Reload servers in Sources UI
|
||||
|
||||
### Connection Failed
|
||||
|
||||
```
|
||||
Error: Failed to connect to MCP server
|
||||
```
|
||||
|
||||
- Verify the command/URL is correct
|
||||
- Check that required packages are installed (`npm install`)
|
||||
- Ensure environment variables are set for authentication
|
||||
- Test the server manually first
|
||||
|
||||
### Tool Not Available
|
||||
|
||||
```
|
||||
Error: Tool 'unknown_tool' not found on server 'myserver'
|
||||
```
|
||||
|
||||
- List available tools with `MCP LIST TOOLS`
|
||||
- Check tool name spelling
|
||||
- Verify server is properly started
|
||||
|
||||
### Authentication Error
|
||||
|
||||
```
|
||||
Error: Authentication failed for MCP server
|
||||
```
|
||||
|
||||
- Check environment variables are set correctly
|
||||
- Verify credentials are valid
|
||||
- Ensure auth type matches server requirements
|
||||
|
||||
---
|
||||
|
||||
## Best Practices
|
||||
|
||||
1. **Use environment variables** for all credentials
|
||||
2. **Set appropriate risk levels** for tools that modify data
|
||||
3. **Enable approval** for destructive operations
|
||||
4. **Comment your mcp.csv** with `#` lines to document servers
|
||||
5. **Test locally** before deploying
|
||||
6. **Start with enabled=false** for new servers until tested
|
||||
|
||||
---
|
||||
|
||||
## See Also
|
||||
|
||||
- [Sources](../04-gbui/apps/sources.md) - Managing MCP servers in the UI
|
||||
- [Autonomous Tasks](../07-gbapp/autonomous-tasks.md) - How Tasks use MCP tools
|
||||
- [MCP Format](../09-tools/mcp-format.md) - MCP tool definition format
|
||||
- [LLM Tools](../09-tools/README.md) - All available tool types
|
||||
|
|
@ -84,6 +84,7 @@ See [Script Execution Flow](./script-execution-flow.md) for complete details.
|
|||
| `FORMAT` | Data | Format strings and dates |
|
||||
| `GENERATE PDF` | Files | Generate PDF from template |
|
||||
| `GET` | Variables | Get variable or API data |
|
||||
| `GOTO` | Control | Jump to label (⚠️ use ON instead) |
|
||||
| `GET BOT MEMORY` | Memory | Retrieve bot-level persisted data |
|
||||
| `GET USER MEMORY` | Memory | Retrieve user-level persisted data (cross-bot) |
|
||||
| `GRAPHQL` | HTTP | Execute GraphQL query |
|
||||
|
|
|
|||
|
|
@ -142,7 +142,7 @@ name,value
|
|||
Start Dialog,start
|
||||
```
|
||||
|
||||
This tells BotServer to run `start.bas` when a conversation begins.
|
||||
This tells botserver to run `start.bas` when a conversation begins.
|
||||
|
||||
## Common Patterns
|
||||
|
||||
|
|
|
|||
|
|
@ -1,6 +1,6 @@
|
|||
# Universal Messaging & Multi-Channel
|
||||
|
||||
BotServer automatically handles conversations across different channels (Web, WhatsApp, Email, etc.) using the same BASIC scripts. Write once, deploy everywhere.
|
||||
botserver automatically handles conversations across different channels (Web, WhatsApp, Email, etc.) using the same BASIC scripts. Write once, deploy everywhere.
|
||||
|
||||
## How It Works
|
||||
|
||||
|
|
@ -34,7 +34,7 @@ Deploy bots directly to Teams channels and direct messages.
|
|||
|
||||
## Channel Detection
|
||||
|
||||
BotServer automatically detects the channel based on the session context. No special code needed:
|
||||
botserver automatically detects the channel based on the session context. No special code needed:
|
||||
|
||||
```basic
|
||||
' This works on ALL channels
|
||||
|
|
@ -46,7 +46,7 @@ TALK "Nice to meet you, " + name
|
|||
|
||||
## Channel-Specific Formatting
|
||||
|
||||
While your code stays the same, BotServer automatically handles channel-specific formatting:
|
||||
While your code stays the same, botserver automatically handles channel-specific formatting:
|
||||
|
||||
### Web
|
||||
- Full HTML support
|
||||
|
|
@ -128,4 +128,4 @@ channel-teams,disabled
|
|||
|
||||
## Summary
|
||||
|
||||
Universal messaging means your BASIC scripts work across all channels without modification. BotServer handles the complexity of channel-specific formatting and delivery, letting you focus on the conversation logic.
|
||||
Universal messaging means your BASIC scripts work across all channels without modification. botserver handles the complexity of channel-specific formatting and delivery, letting you focus on the conversation logic.
|
||||
|
|
|
|||
|
|
@ -4,7 +4,7 @@ Architecture and deployment reference for developers.
|
|||
|
||||
## Overview
|
||||
|
||||
BotServer is built in Rust with a modular architecture. Extend it by creating custom keywords, services, or entire applications.
|
||||
botserver is built in Rust with a modular architecture. Extend it by creating custom keywords, services, or entire applications.
|
||||
|
||||
## Architecture
|
||||
|
||||
|
|
@ -51,6 +51,22 @@ pub fn my_keyword(context: &mut EvalContext) -> Result<Dynamic, Box<EvalError>>
|
|||
|
||||
Register in `keywords/mod.rs` and rebuild.
|
||||
|
||||
## Autonomous Task AI
|
||||
|
||||
General Bots enables **autonomous task execution** where the machine does the work:
|
||||
|
||||
```
|
||||
Human describes intent → AI plans → AI generates → AI deploys → AI monitors
|
||||
```
|
||||
|
||||
Key concepts:
|
||||
- **Intent Compilation** - LLM translates natural language to execution plans
|
||||
- **CREATE SITE** - Generates HTMX apps bound to botserver API
|
||||
- **.gbdrive** - Cloud-synced workspace for all task files
|
||||
- **Autonomous Execution** - System runs plans with approval gates
|
||||
|
||||
See [Autonomous Task AI](./autonomous-tasks.md) for complete documentation.
|
||||
|
||||
## Chapter Contents
|
||||
|
||||
- [Architecture Overview](./architecture.md) - System design
|
||||
|
|
@ -60,6 +76,7 @@ Register in `keywords/mod.rs` and rebuild.
|
|||
- [Scaling](./scaling.md) - Load balancing
|
||||
- [Infrastructure](./infrastructure.md) - Hardware planning
|
||||
- [Observability](./observability.md) - Monitoring
|
||||
- [Autonomous Task AI](./autonomous-tasks.md) - Machine does the work
|
||||
- [Custom Keywords](./custom-keywords.md) - Extending BASIC
|
||||
- [Services](./services.md) - Service layer
|
||||
|
||||
|
|
|
|||
|
|
@ -1,6 +1,6 @@
|
|||
# Architecture Overview
|
||||
|
||||
BotServer follows a modular architecture designed for scalability, maintainability, and extensibility. Each module handles specific responsibilities and communicates through well-defined interfaces. This chapter provides a comprehensive tour of the system architecture and how components work together.
|
||||
botserver follows a modular architecture designed for scalability, maintainability, and extensibility. Each module handles specific responsibilities and communicates through well-defined interfaces. This chapter provides a comprehensive tour of the system architecture and how components work together.
|
||||
|
||||
|
||||
## Core Architecture
|
||||
|
|
@ -9,11 +9,11 @@ The architecture diagrams below illustrate the major components and their relati
|
|||
|
||||
### Data Flow Architecture
|
||||
|
||||
<img src="../assets/chapter-07/data-flow.svg" alt="BotServer Data Flow Architecture" style="max-height: 400px; width: 100%; object-fit: contain;">
|
||||
<img src="../assets/chapter-07/data-flow.svg" alt="botserver Data Flow Architecture" style="max-height: 400px; width: 100%; object-fit: contain;">
|
||||
|
||||
### System Architecture
|
||||
|
||||
<img src="../assets/chapter-07/system-architecture.svg" alt="BotServer System Architecture" style="max-height: 400px; width: 100%; object-fit: contain;">
|
||||
<img src="../assets/chapter-07/system-architecture.svg" alt="botserver System Architecture" style="max-height: 400px; width: 100%; object-fit: contain;">
|
||||
|
||||
|
||||
## Module Dependency Graph
|
||||
|
|
@ -136,7 +136,7 @@ Access control mechanisms ensure appropriate authorization. Role-based permissio
|
|||
|
||||
### Container Structure
|
||||
|
||||
Production deployments typically use containers for isolation and portability. The main application container runs the BotServer binary. PostgreSQL runs in a separate database container. Drive storage uses an S3-compatible container like MinIO. The cache layer uses Valkey in its own container. Qdrant provides vector database functionality in another container. Nginx serves as a reverse proxy for external traffic.
|
||||
Production deployments typically use containers for isolation and portability. The main application container runs the botserver binary. PostgreSQL runs in a separate database container. Drive storage uses an S3-compatible container like MinIO. The cache layer uses Valkey in its own container. Qdrant provides vector database functionality in another container. Nginx serves as a reverse proxy for external traffic.
|
||||
|
||||
### Scaling Strategy
|
||||
|
||||
|
|
|
|||
611
src/07-gbapp/autonomous-tasks.md
Normal file
611
src/07-gbapp/autonomous-tasks.md
Normal file
|
|
@ -0,0 +1,611 @@
|
|||
# Autonomous Task AI
|
||||
|
||||
> **The Machine Does the Work**
|
||||
|
||||
---
|
||||
|
||||
<img src="../assets/chapter-07/autonomous-task-flow.svg" alt="Autonomous Task AI Flow" style="max-width: 100%; height: auto;">
|
||||
|
||||
---
|
||||
|
||||
## Overview
|
||||
|
||||
General Bots transforms how work gets done. Instead of humans executing tasks step-by-step, you describe what you want and the AI autonomously builds, deploys, and manages everything.
|
||||
|
||||
**Traditional approach:**
|
||||
```
|
||||
Human thinks → Human plans → Human codes → Human deploys → Human maintains
|
||||
```
|
||||
|
||||
**General Bots approach:**
|
||||
```
|
||||
Human describes intent → AI plans → AI generates → AI deploys → AI monitors
|
||||
```
|
||||
|
||||
This is not just task automation - it's **autonomous task execution** where the LLM acts as the brain that understands, plans, and accomplishes complex work.
|
||||
|
||||
---
|
||||
|
||||
## Core Architecture
|
||||
|
||||
### The Foundation: .gbai + .gbdrive
|
||||
|
||||
Every autonomous task operates within the General Bots package structure:
|
||||
|
||||
```
|
||||
project.gbai/ # The AI workspace
|
||||
├── project.gbdialog/ # BASIC scripts (auto-generated)
|
||||
│ ├── start.bas # Entry point
|
||||
│ └── tools/ # Generated tools
|
||||
├── project.gbkb/ # Knowledge base
|
||||
│ └── docs/ # Reference documents
|
||||
├── project.gbot/ # Configuration
|
||||
│ └── config.csv # Bot settings
|
||||
├── project.gbdrive/ # Online storage (MinIO bucket)
|
||||
│ ├── assets/ # Generated assets
|
||||
│ ├── data/ # Task data files
|
||||
│ └── output/ # Produced artifacts
|
||||
└── project.gbtheme/ # UI customization
|
||||
```
|
||||
|
||||
**Key insight:** The `.gbdrive` folder is a live link to cloud storage (MinIO/S3). Everything the AI creates, processes, or outputs lives here - accessible via API, web UI, or direct bucket access.
|
||||
|
||||
---
|
||||
|
||||
## How Autonomous Tasks Work
|
||||
|
||||
### 1. Intent Compilation
|
||||
|
||||
When you describe what you want, the LLM performs **intent compilation**:
|
||||
|
||||
```
|
||||
User: "Create a CRM for tracking real estate leads with email automation"
|
||||
|
||||
LLM Analysis:
|
||||
├── Action: CREATE
|
||||
├── Target: CRM application
|
||||
├── Domain: Real estate
|
||||
├── Features:
|
||||
│ ├── Lead tracking
|
||||
│ ├── Email automation
|
||||
│ └── Contact management
|
||||
├── Integrations: Email service
|
||||
└── Output: HTMX web application
|
||||
```
|
||||
|
||||
### 2. Plan Generation
|
||||
|
||||
The AI generates an execution plan with ordered steps:
|
||||
|
||||
| Step | Priority | Description | Keywords |
|
||||
|------|----------|-------------|----------|
|
||||
| 1 | CRITICAL | Create database schema | NEW_TABLE, COLUMN |
|
||||
| 2 | HIGH | Setup authentication | OAUTH, JWT |
|
||||
| 3 | HIGH | Build lead management UI | CREATE SITE, FORM |
|
||||
| 4 | MEDIUM | Create email templates | CREATE DRAFT |
|
||||
| 5 | MEDIUM | Setup automation rules | SET SCHEDULE, ON |
|
||||
| 6 | LOW | Deploy and configure | DEPLOY |
|
||||
|
||||
### 3. Autonomous Execution
|
||||
|
||||
The system executes each step, pausing only for:
|
||||
- High-risk operations requiring approval
|
||||
- Decisions that need human input
|
||||
- External integrations requiring credentials
|
||||
|
||||
---
|
||||
|
||||
## CREATE SITE: The App Generator
|
||||
|
||||
`CREATE SITE` is the cornerstone keyword for autonomous app creation. It generates complete HTMX-based web applications bound to the botserver API.
|
||||
|
||||
### How It Works
|
||||
|
||||
```basic
|
||||
CREATE SITE "crm", "bottemplates/apps/crud", "Build a real estate CRM with lead tracking"
|
||||
```
|
||||
|
||||
**Execution flow:**
|
||||
|
||||
1. **Template Loading**
|
||||
- Reads HTML templates from `bottemplates/apps/crud/`
|
||||
- Combines all `.html` files as reference
|
||||
- Extracts HTMX patterns and component structures
|
||||
|
||||
2. **LLM Generation**
|
||||
- Sends combined templates + prompt to LLM
|
||||
- Generates new `index.html` with:
|
||||
- HTMX attributes for dynamic behavior
|
||||
- API bindings to botserver endpoints
|
||||
- CSS using local `_assets` only (no external CDNs)
|
||||
|
||||
3. **Deployment**
|
||||
- Creates folder at `<site_path>/crm/`
|
||||
- Writes generated `index.html`
|
||||
- Copies required assets
|
||||
- Site immediately available at `/crm`
|
||||
|
||||
### Generated App Structure
|
||||
|
||||
```
|
||||
sites/crm/
|
||||
├── index.html # LLM-generated HTMX app
|
||||
├── _assets/
|
||||
│ ├── htmx.min.js # HTMX library
|
||||
│ ├── app.js # Custom interactions
|
||||
│ └── styles.css # Themed styles
|
||||
└── api/ # Handled by botserver
|
||||
```
|
||||
|
||||
### HTMX + GB API Pattern
|
||||
|
||||
Generated apps use HTMX to communicate with botserver:
|
||||
|
||||
```html
|
||||
<!-- Lead list with live updates -->
|
||||
<div id="leads"
|
||||
hx-get="/api/crm/leads"
|
||||
hx-trigger="load, every 30s"
|
||||
hx-swap="innerHTML">
|
||||
Loading leads...
|
||||
</div>
|
||||
|
||||
<!-- Add new lead form -->
|
||||
<form hx-post="/api/crm/leads"
|
||||
hx-target="#leads"
|
||||
hx-swap="afterbegin"
|
||||
hx-indicator="#saving">
|
||||
<input name="name" placeholder="Lead name" required>
|
||||
<input name="email" type="email" placeholder="Email">
|
||||
<input name="phone" placeholder="Phone">
|
||||
<button type="submit">
|
||||
<span class="btn-text">Add Lead</span>
|
||||
<span id="saving" class="htmx-indicator">Saving...</span>
|
||||
</button>
|
||||
</form>
|
||||
|
||||
<!-- Lead detail with inline editing -->
|
||||
<div class="lead-card"
|
||||
hx-get="/api/crm/leads/${id}"
|
||||
hx-trigger="click"
|
||||
hx-target="#detail-panel">
|
||||
<h3>${name}</h3>
|
||||
<p>${email}</p>
|
||||
</div>
|
||||
```
|
||||
|
||||
### API Binding
|
||||
|
||||
The generated HTMX calls map to botserver endpoints automatically:
|
||||
|
||||
| HTMX Call | Botserver Handler | BASIC Equivalent |
|
||||
|-----------|-------------------|------------------|
|
||||
| `GET /api/crm/leads` | Query handler | `FIND "leads"` |
|
||||
| `POST /api/crm/leads` | Insert handler | `UPSERT "leads"` |
|
||||
| `PUT /api/crm/leads/:id` | Update handler | `SET "leads"` |
|
||||
| `DELETE /api/crm/leads/:id` | Delete handler | `DELETE "leads"` |
|
||||
|
||||
---
|
||||
|
||||
## The .gbdrive Workspace
|
||||
|
||||
Every autonomous task uses `.gbdrive` as its workspace - a cloud-synced folder structure:
|
||||
|
||||
### Storage Architecture
|
||||
|
||||
```
|
||||
.gbdrive/ (MinIO bucket)
|
||||
├── tasks/
|
||||
│ ├── task-001/
|
||||
│ │ ├── plan.json # Execution plan
|
||||
│ │ ├── progress.json # Current state
|
||||
│ │ ├── logs/ # Execution logs
|
||||
│ │ └── output/ # Generated files
|
||||
│ └── task-002/
|
||||
│ └── ...
|
||||
├── apps/
|
||||
│ ├── crm/
|
||||
│ │ ├── index.html
|
||||
│ │ └── _assets/
|
||||
│ └── dashboard/
|
||||
│ └── ...
|
||||
├── data/
|
||||
│ ├── leads.json
|
||||
│ ├── contacts.json
|
||||
│ └── reports/
|
||||
└── assets/
|
||||
├── templates/
|
||||
├── images/
|
||||
└── documents/
|
||||
```
|
||||
|
||||
### Accessing .gbdrive
|
||||
|
||||
**Via API:**
|
||||
```javascript
|
||||
// List files
|
||||
fetch('/api/drive/list?path=tasks/task-001')
|
||||
|
||||
// Download file
|
||||
fetch('/api/drive/download?path=apps/crm/index.html')
|
||||
|
||||
// Upload file
|
||||
fetch('/api/drive/upload', {
|
||||
method: 'POST',
|
||||
body: formData
|
||||
})
|
||||
```
|
||||
|
||||
**Via BASIC:**
|
||||
```basic
|
||||
' List drive contents
|
||||
files = DIR ".gbdrive/tasks"
|
||||
|
||||
' Copy to drive
|
||||
COPY "report.pdf" TO ".gbdrive/output/"
|
||||
|
||||
' Read from drive
|
||||
data = LOAD ".gbdrive/data/leads.json"
|
||||
```
|
||||
|
||||
**Via rclone:**
|
||||
```bash
|
||||
# Sync local to drive
|
||||
rclone sync ./mybot.gbai drive:mybot --watch
|
||||
|
||||
# Download from drive
|
||||
rclone copy drive:mybot/output ./local-output
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Execution Modes
|
||||
|
||||
### Semi-Automatic (Recommended)
|
||||
|
||||
The AI executes autonomously but pauses for critical decisions:
|
||||
|
||||
```
|
||||
[Step 1] Creating database... ✓
|
||||
[Step 2] Setting up auth... ✓
|
||||
[Step 3] Building UI... ✓
|
||||
[Step 4] ⚠️ APPROVAL REQUIRED
|
||||
Action: Send 500 welcome emails
|
||||
Impact: Email quota usage
|
||||
[Approve] [Modify] [Skip]
|
||||
```
|
||||
|
||||
### Supervised
|
||||
|
||||
Every step requires explicit approval:
|
||||
|
||||
```
|
||||
[Step 1] Create database schema
|
||||
Tables: leads, contacts, activities
|
||||
[Approve] [Modify] [Skip]
|
||||
```
|
||||
|
||||
### Fully Automatic
|
||||
|
||||
Complete autonomous execution without stops:
|
||||
|
||||
```
|
||||
Task: "Build CRM for real estate"
|
||||
Status: RUNNING
|
||||
Progress: ████████████░░░░ 75%
|
||||
Current: Generating email templates
|
||||
ETA: 12 minutes
|
||||
```
|
||||
|
||||
### Dry Run
|
||||
|
||||
Simulates execution without making changes:
|
||||
|
||||
```
|
||||
[SIMULATION] Step 1: Would create 3 tables
|
||||
[SIMULATION] Step 2: Would generate 5 HTML files
|
||||
[SIMULATION] Step 3: Would create 2 email templates
|
||||
[SIMULATION] Estimated cost: $0.45
|
||||
[SIMULATION] Estimated time: 25 minutes
|
||||
|
||||
Proceed with actual execution? [Yes] [No]
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Generated BASIC Programs
|
||||
|
||||
Behind every autonomous task is a BASIC program. The LLM generates executable code:
|
||||
|
||||
```basic
|
||||
' =============================================================================
|
||||
' AUTO-GENERATED: Real Estate CRM
|
||||
' Created: 2024-01-15
|
||||
' =============================================================================
|
||||
|
||||
PLAN_START "Real Estate CRM", "Lead tracking with email automation"
|
||||
STEP 1, "Create database", CRITICAL
|
||||
STEP 2, "Build UI", HIGH
|
||||
STEP 3, "Setup automation", MEDIUM
|
||||
PLAN_END
|
||||
|
||||
' -----------------------------------------------------------------------------
|
||||
' STEP 1: Database Schema
|
||||
' -----------------------------------------------------------------------------
|
||||
|
||||
NEW_TABLE "leads"
|
||||
COLUMN "id", UUID, PRIMARY KEY
|
||||
COLUMN "name", STRING, REQUIRED
|
||||
COLUMN "email", STRING
|
||||
COLUMN "phone", STRING
|
||||
COLUMN "status", STRING, DEFAULT "new"
|
||||
COLUMN "source", STRING
|
||||
COLUMN "created_at", TIMESTAMP
|
||||
SAVE_TABLE
|
||||
|
||||
NEW_TABLE "activities"
|
||||
COLUMN "id", UUID, PRIMARY KEY
|
||||
COLUMN "lead_id", UUID, FOREIGN KEY "leads.id"
|
||||
COLUMN "type", STRING
|
||||
COLUMN "notes", TEXT
|
||||
COLUMN "created_at", TIMESTAMP
|
||||
SAVE_TABLE
|
||||
|
||||
' -----------------------------------------------------------------------------
|
||||
' STEP 2: Generate Application
|
||||
' -----------------------------------------------------------------------------
|
||||
|
||||
CREATE SITE "crm", "bottemplates/apps/crud", "Real estate CRM with:
|
||||
- Lead list with filtering and search
|
||||
- Lead detail view with activity timeline
|
||||
- Quick add form
|
||||
- Status pipeline view (Kanban)
|
||||
- Email integration buttons"
|
||||
|
||||
' -----------------------------------------------------------------------------
|
||||
' STEP 3: Automation Rules
|
||||
' -----------------------------------------------------------------------------
|
||||
|
||||
ON "leads" INSERT DO
|
||||
' Send welcome email to new leads
|
||||
IF NEW.email != "" THEN
|
||||
CREATE DRAFT NEW.email, "Welcome to Our Service", "
|
||||
Hi " + NEW.name + ",
|
||||
Thank you for your interest...
|
||||
"
|
||||
END IF
|
||||
|
||||
' Log activity
|
||||
UPSERT "activities"
|
||||
SET lead_id = NEW.id
|
||||
SET type = "created"
|
||||
SET notes = "Lead created from " + NEW.source
|
||||
END ON
|
||||
|
||||
' Schedule daily digest
|
||||
SET SCHEDULE "0 9 * * *" DO
|
||||
leads = FIND "leads", "status=new AND created_at > yesterday"
|
||||
IF COUNT(leads) > 0 THEN
|
||||
report = LLM "Create summary of " + COUNT(leads) + " new leads"
|
||||
SEND MAIL "sales@company.com", "Daily Lead Digest", report
|
||||
END IF
|
||||
END SCHEDULE
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Task Lifecycle
|
||||
|
||||
### States
|
||||
|
||||
| State | Description |
|
||||
|-------|-------------|
|
||||
| `draft` | Task created, intent captured |
|
||||
| `compiling` | LLM generating execution plan |
|
||||
| `ready` | Plan generated, awaiting execution |
|
||||
| `running` | Currently executing steps |
|
||||
| `paused` | Execution paused by user |
|
||||
| `pending_approval` | Waiting for approval on high-risk step |
|
||||
| `waiting_decision` | Needs user input to continue |
|
||||
| `completed` | Successfully finished all steps |
|
||||
| `failed` | Encountered unrecoverable error |
|
||||
| `cancelled` | Stopped by user |
|
||||
|
||||
### Monitoring
|
||||
|
||||
Real-time task monitoring via WebSocket:
|
||||
|
||||
```javascript
|
||||
// Connect to task updates
|
||||
const ws = new WebSocket('wss://host/ws/autotask');
|
||||
|
||||
ws.onmessage = (event) => {
|
||||
const data = JSON.parse(event.data);
|
||||
switch (data.type) {
|
||||
case 'step_progress':
|
||||
updateProgressBar(data.progress);
|
||||
break;
|
||||
case 'approval_required':
|
||||
showApprovalDialog(data.approval);
|
||||
break;
|
||||
case 'task_completed':
|
||||
showSuccessNotification(data.task);
|
||||
break;
|
||||
}
|
||||
};
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Building Your Own Autonomous Workflows
|
||||
|
||||
### Example: Automated Report Generator
|
||||
|
||||
```basic
|
||||
' Intent: "Generate weekly sales report every Monday"
|
||||
|
||||
SET SCHEDULE "0 8 * * 1" DO
|
||||
' Gather data
|
||||
sales = FIND "orders", "created_at > last_week"
|
||||
customers = FIND "customers", "orders > 0"
|
||||
|
||||
' Generate analysis
|
||||
analysis = LLM "Analyze sales data: " + JSON(sales)
|
||||
|
||||
' Create report site
|
||||
CREATE SITE "report-" + TODAY(), "bottemplates/apps/dashboard", analysis
|
||||
|
||||
' Notify stakeholders
|
||||
SEND MAIL "team@company.com", "Weekly Sales Report", "
|
||||
Report ready: /report-" + TODAY()
|
||||
"
|
||||
END SCHEDULE
|
||||
```
|
||||
|
||||
### Example: Customer Onboarding Automation
|
||||
|
||||
```basic
|
||||
' Triggered when new customer signs up
|
||||
ON "customers" INSERT DO
|
||||
' Create personalized welcome site
|
||||
welcome_content = LLM "Create welcome page for " + NEW.name + " in " + NEW.industry
|
||||
CREATE SITE "welcome-" + NEW.id, "bottemplates/apps/crud", welcome_content
|
||||
|
||||
' Schedule follow-up sequence
|
||||
CREATE TASK "Follow up with " + NEW.name, "Call in 3 days"
|
||||
|
||||
' Send welcome email with site link
|
||||
CREATE DRAFT NEW.email, "Welcome!", "
|
||||
Hi " + NEW.name + ",
|
||||
Your personalized portal is ready: /welcome-" + NEW.id
|
||||
"
|
||||
END ON
|
||||
```
|
||||
|
||||
### Example: Dynamic Dashboard Builder
|
||||
|
||||
```basic
|
||||
' User asks: "Create a dashboard showing our KPIs"
|
||||
|
||||
' Step 1: Analyze available data
|
||||
tables = SHOW TABLES
|
||||
schema = LLM "Analyze schema for KPI opportunities: " + JSON(tables)
|
||||
|
||||
' Step 2: Generate dashboard
|
||||
CREATE SITE "dashboard", "bottemplates/apps/dashboard", "
|
||||
Create executive dashboard with:
|
||||
" + schema + "
|
||||
|
||||
Include:
|
||||
- Real-time metrics cards
|
||||
- Trend charts (last 30 days)
|
||||
- Comparison to previous period
|
||||
- Export to PDF button
|
||||
"
|
||||
|
||||
' Step 3: Set auto-refresh
|
||||
TALK "Dashboard created at /dashboard with live updates"
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Integration with GB Infrastructure
|
||||
|
||||
### How Apps Use botserver
|
||||
|
||||
Generated HTMX apps don't need their own backend - they use botserver's API:
|
||||
|
||||
```
|
||||
┌─────────────────────────────────────────────────────────────┐
|
||||
│ Generated HTMX App │
|
||||
│ ┌─────────┐ ┌─────────┐ ┌─────────┐ ┌─────────┐ │
|
||||
│ │ Forms │ │ Lists │ │ Charts │ │ Actions │ │
|
||||
│ └────┬────┘ └────┬────┘ └────┬────┘ └────┬────┘ │
|
||||
│ │ │ │ │ │
|
||||
│ └────────────┴────────────┴────────────┘ │
|
||||
│ │ HTMX │
|
||||
└─────────────────────────┼───────────────────────────────────┘
|
||||
│
|
||||
┌─────────────────────────┼───────────────────────────────────┐
|
||||
│ botserver API │
|
||||
│ ┌──────────┐ ┌──────────┐ ┌──────────┐ ┌──────────┐ │
|
||||
│ │ CRUD │ │ LLM │ │ Drive │ │ Mail │ │
|
||||
│ │ /api/db │ │ /api/llm │ │/api/drive│ │/api/mail │ │
|
||||
│ └────┬─────┘ └────┬─────┘ └────┬─────┘ └────┬─────┘ │
|
||||
│ │ │ │ │ │
|
||||
│ ┌────┴─────────────┴─────────────┴─────────────┴────┐ │
|
||||
│ │ PostgreSQL + MinIO + LLM │ │
|
||||
│ └────────────────────────────────────────────────────┘ │
|
||||
└─────────────────────────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
### Available API Endpoints
|
||||
|
||||
| Endpoint | Purpose | HTMX Usage |
|
||||
|----------|---------|------------|
|
||||
| `/api/db/{table}` | CRUD operations | `hx-get`, `hx-post`, `hx-put`, `hx-delete` |
|
||||
| `/api/llm/complete` | LLM generation | `hx-post` with prompt |
|
||||
| `/api/drive/*` | File operations | `hx-get` for download, `hx-post` for upload |
|
||||
| `/api/mail/send` | Email sending | `hx-post` with recipients |
|
||||
| `/api/chat` | Conversational AI | WebSocket |
|
||||
|
||||
---
|
||||
|
||||
## Best Practices
|
||||
|
||||
### Writing Effective Intents
|
||||
|
||||
**Good:**
|
||||
```
|
||||
"Create a project management app for our marketing team with:
|
||||
- Kanban board for campaign tasks
|
||||
- Team member assignment
|
||||
- Deadline tracking with reminders
|
||||
- File attachments per task
|
||||
- Weekly progress reports"
|
||||
```
|
||||
|
||||
**Bad:**
|
||||
```
|
||||
"Make an app"
|
||||
```
|
||||
|
||||
### Template Organization
|
||||
|
||||
Keep templates organized for reuse:
|
||||
|
||||
```
|
||||
templates/
|
||||
├── app/ # Full application templates
|
||||
│ ├── dashboard.html
|
||||
│ ├── crud-list.html
|
||||
│ └── form-wizard.html
|
||||
├── components/ # Reusable components
|
||||
│ ├── data-table.html
|
||||
│ ├── chart-card.html
|
||||
│ └── form-field.html
|
||||
├── emails/ # Email templates
|
||||
│ ├── welcome.html
|
||||
│ └── notification.html
|
||||
└── reports/ # Report templates
|
||||
├── summary.html
|
||||
└── detailed.html
|
||||
```
|
||||
|
||||
### Security Considerations
|
||||
|
||||
- All generated apps inherit botserver authentication
|
||||
- API calls require valid session tokens
|
||||
- File uploads go through virus scanning
|
||||
- Database operations respect row-level security
|
||||
- LLM outputs are sanitized before rendering
|
||||
|
||||
---
|
||||
|
||||
## See Also
|
||||
|
||||
- [CREATE SITE Keyword](../06-gbdialog/keyword-create-site.md) - Detailed syntax
|
||||
- [.gbai Architecture](../02-templates/gbai.md) - Package structure
|
||||
- [.gbdrive Storage](../02-templates/gbdrive.md) - File management
|
||||
- [HTMX Architecture](../04-gbui/htmx-architecture.md) - UI patterns
|
||||
- [API Reference](../10-rest/README.md) - botserver endpoints
|
||||
|
|
@ -1,6 +1,6 @@
|
|||
# Building from Source
|
||||
|
||||
This guide covers building BotServer from source, including dependencies, feature flags, and platform-specific considerations.
|
||||
This guide covers building botserver from source, including dependencies, feature flags, and platform-specific considerations.
|
||||
|
||||
## Prerequisites
|
||||
|
||||
|
|
@ -72,8 +72,8 @@ choco install postgresql
|
|||
## Clone Repository
|
||||
|
||||
```bash
|
||||
git clone https://github.com/GeneralBots/BotServer.git
|
||||
cd BotServer
|
||||
git clone https://github.com/GeneralBots/botserver.git
|
||||
cd botserver
|
||||
```
|
||||
|
||||
## Build Configurations
|
||||
|
|
@ -137,7 +137,7 @@ cargo build --release --all-features
|
|||
|
||||
## Feature Flags
|
||||
|
||||
BotServer supports the following features defined in `Cargo.toml`:
|
||||
botserver supports the following features defined in `Cargo.toml`:
|
||||
|
||||
```toml
|
||||
[features]
|
||||
|
|
@ -493,9 +493,9 @@ curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh -s -- -y
|
|||
source \$HOME/.cargo/env
|
||||
"
|
||||
|
||||
# Build BotServer
|
||||
# Build botserver
|
||||
lxc-attach -n botserver-build -- bash -c "
|
||||
git clone https://github.com/GeneralBots/BotServer /build
|
||||
git clone https://github.com/GeneralBots/botserver /build
|
||||
cd /build
|
||||
source \$HOME/.cargo/env
|
||||
cargo build --release --no-default-features
|
||||
|
|
@ -526,7 +526,7 @@ After building:
|
|||
|
||||
1. Run the bootstrap process to install dependencies
|
||||
2. Configure `.env` file with database credentials
|
||||
3. Start BotServer and access web interface
|
||||
3. Start botserver and access web interface
|
||||
4. Create your first bot from templates
|
||||
|
||||
See [Chapter 01: Run and Talk](../chapter-01/README.md) for next steps.
|
||||
|
|
@ -1,6 +1,6 @@
|
|||
# Cargo Tools Reference
|
||||
|
||||
This chapter documents essential Cargo tools for BotServer development, including code coverage, security auditing, performance profiling, and code quality tools.
|
||||
This chapter documents essential Cargo tools for botserver development, including code coverage, security auditing, performance profiling, and code quality tools.
|
||||
|
||||
## Overview
|
||||
|
||||
|
|
|
|||
|
|
@ -1,6 +1,6 @@
|
|||
# Container Deployment (LXC)
|
||||
|
||||
BotServer uses LXC (Linux Containers) for isolated component deployment with system-level containerization.
|
||||
botserver uses LXC (Linux Containers) for isolated component deployment with system-level containerization.
|
||||
|
||||
## What is LXC?
|
||||
|
||||
|
|
|
|||
|
|
@ -1,6 +1,6 @@
|
|||
# Module Structure
|
||||
|
||||
BotServer is a single Rust crate (not a workspace) with multiple modules. The application is defined in `Cargo.toml` as the `botserver` crate, version 6.0.8.
|
||||
botserver is a single Rust crate (not a workspace) with multiple modules. The application is defined in `Cargo.toml` as the `botserver` crate, version 6.0.8.
|
||||
|
||||
## Main Entry Points
|
||||
|
||||
|
|
|
|||
|
|
@ -1,10 +1,10 @@
|
|||
# Creating Custom Keywords
|
||||
|
||||
BotServer's BASIC scripting language can be extended with custom keywords. All keywords are implemented as Rust functions in the `src/basic/keywords/` directory.
|
||||
botserver's BASIC scripting language can be extended with custom keywords. All keywords are implemented as Rust functions in the `src/basic/keywords/` directory.
|
||||
|
||||
## Overview
|
||||
|
||||
Keywords in BotServer are Rust functions that get registered with the Rhai scripting engine. They provide the core functionality that BASIC scripts can use to interact with the system.
|
||||
Keywords in botserver are Rust functions that get registered with the Rhai scripting engine. They provide the core functionality that BASIC scripts can use to interact with the system.
|
||||
|
||||
## Keyword Implementation Structure
|
||||
|
||||
|
|
@ -315,4 +315,4 @@ pub fn save_data_keyword(
|
|||
|
||||
## Summary
|
||||
|
||||
Creating custom keywords extends BotServer's BASIC language capabilities. Keywords are Rust functions registered with the Rhai engine that provide access to system features, databases, external APIs, and more. Follow the patterns shown above to create robust, thread-safe keywords that integrate seamlessly with the BotServer ecosystem.
|
||||
Creating custom keywords extends botserver's BASIC language capabilities. Keywords are Rust functions registered with the Rhai engine that provide access to system features, databases, external APIs, and more. Follow the patterns shown above to create robust, thread-safe keywords that integrate seamlessly with the botserver ecosystem.
|
||||
|
|
@ -1,6 +1,6 @@
|
|||
# Adding Dependencies
|
||||
|
||||
BotServer is a single-crate Rust application, so all dependencies are managed through the root `Cargo.toml` file. This guide covers how to add, update, and manage dependencies effectively.
|
||||
botserver is a single-crate Rust application, so all dependencies are managed through the root `Cargo.toml` file. This guide covers how to add, update, and manage dependencies effectively.
|
||||
|
||||
## Adding a Dependency
|
||||
|
||||
|
|
@ -106,7 +106,7 @@ core-foundation = "0.9"
|
|||
|
||||
## Existing Dependencies
|
||||
|
||||
BotServer relies on a comprehensive set of dependencies organized by functionality.
|
||||
botserver relies on a comprehensive set of dependencies organized by functionality.
|
||||
|
||||
### Web Framework
|
||||
|
||||
|
|
@ -279,7 +279,7 @@ cargo tree --duplicates
|
|||
|
||||
## Feature Management
|
||||
|
||||
BotServer uses feature flags to enable optional functionality, allowing users to compile only what they need.
|
||||
botserver uses feature flags to enable optional functionality, allowing users to compile only what they need.
|
||||
|
||||
### Current Features
|
||||
|
||||
|
|
|
|||
|
|
@ -181,7 +181,7 @@ spec:
|
|||
|
||||
| Service | Endpoint |
|
||||
|---------|----------|
|
||||
| BotServer | `GET /health` |
|
||||
| botserver | `GET /health` |
|
||||
| PostgreSQL | `pg_isready` |
|
||||
| MinIO | `GET /minio/health/live` |
|
||||
| Qdrant | `GET /health` |
|
||||
|
|
|
|||
|
|
@ -1,6 +1,6 @@
|
|||
# Example: Creating a New gbapp Virtual Crate
|
||||
|
||||
This guide walks through creating a new gbapp virtual crate called `analytics` that adds analytics capabilities to BotServer.
|
||||
This guide walks through creating a new gbapp virtual crate called `analytics` that adds analytics capabilities to botserver.
|
||||
|
||||
## Step 1: Create the Module Structure
|
||||
|
||||
|
|
@ -351,4 +351,4 @@ Creating a gbapp virtual crate is straightforward:
|
|||
4. Register with core
|
||||
5. Use in BASIC scripts
|
||||
|
||||
Your gbapp becomes part of BotServer's compiled binary, providing native performance while maintaining the conceptual clarity of the package system. Most importantly, remember that the implementation should be minimal - let BASIC + LLM handle the complexity!
|
||||
Your gbapp becomes part of botserver's compiled binary, providing native performance while maintaining the conceptual clarity of the package system. Most importantly, remember that the implementation should be minimal - let BASIC + LLM handle the complexity!
|
||||
|
|
@ -266,9 +266,9 @@ WantedBy=multi-user.target
|
|||
|
||||
## Container Lifecycle
|
||||
|
||||
The startup flow begins with creating the LXC container from a template, then configuring resources for CPU, memory, and storage, then starting the BotServer binary, and finally marking the container as ready and adding it to the load balancer pool.
|
||||
The startup flow begins with creating the LXC container from a template, then configuring resources for CPU, memory, and storage, then starting the botserver binary, and finally marking the container as ready and adding it to the load balancer pool.
|
||||
|
||||
The shutdown flow begins with an active container serving requests, then draining to stop accepting new connections, then stopping with a graceful BotServer shutdown, and finally deleting or returning the container to the pool.
|
||||
The shutdown flow begins with an active container serving requests, then draining to stop accepting new connections, then stopping with a graceful botserver shutdown, and finally deleting or returning the container to the pool.
|
||||
|
||||
## Load Balancing
|
||||
|
||||
|
|
@ -423,7 +423,7 @@ observability-bucket,metrics
|
|||
|
||||
### Option 2: Vector + InfluxDB (Recommended)
|
||||
|
||||
Vector serves as a log and metric aggregator. BotServer logs flow to Vector which pipelines them to InfluxDB for metrics storage and Grafana for dashboards.
|
||||
Vector serves as a log and metric aggregator. botserver logs flow to Vector which pipelines them to InfluxDB for metrics storage and Grafana for dashboards.
|
||||
|
||||
Vector configuration:
|
||||
|
||||
|
|
|
|||
|
|
@ -10,7 +10,7 @@ This automated approach means administrators don't need to instrument code or co
|
|||
|
||||
## Log Directory Organization
|
||||
|
||||
The logging system organizes output by component within the `./botserver-stack/logs/` directory. System logs from the main BotServer application appear in the system subdirectory. Storage service operations are captured in the drive subdirectory. Database activity from PostgreSQL goes to the tables subdirectory. The cache subdirectory contains logs from the caching layer. LLM server interactions are recorded in the llm subdirectory.
|
||||
The logging system organizes output by component within the `./botserver-stack/logs/` directory. System logs from the main botserver application appear in the system subdirectory. Storage service operations are captured in the drive subdirectory. Database activity from PostgreSQL goes to the tables subdirectory. The cache subdirectory contains logs from the caching layer. LLM server interactions are recorded in the llm subdirectory.
|
||||
|
||||
Additional services have their own logging locations. Email service logs appear in the email subdirectory. Identity and authentication events are captured in the directory subdirectory. Vector database operations go to the vectordb subdirectory. Video meeting activities are logged in the meet subdirectory.
|
||||
|
||||
|
|
@ -24,7 +24,7 @@ Configuration for the observability pipeline resides in the monitoring configura
|
|||
|
||||
## Log Format Conventions
|
||||
|
||||
BotServer generates logs in a standard format that includes the timestamp in ISO 8601 format with millisecond precision, the log level indicating severity, the module path identifying the code location, and the message describing what occurred. This structured format enables automated parsing while remaining human-readable for direct inspection.
|
||||
botserver generates logs in a standard format that includes the timestamp in ISO 8601 format with millisecond precision, the log level indicating severity, the module path identifying the code location, and the message describing what occurred. This structured format enables automated parsing while remaining human-readable for direct inspection.
|
||||
|
||||
The pipeline parses these logs automatically, extracting fields for indexing and routing. Errors are identified by level and routed to alerting systems while informational messages flow to long-term storage for historical analysis.
|
||||
|
||||
|
|
|
|||
|
|
@ -1,6 +1,6 @@
|
|||
# Service Layer
|
||||
|
||||
BotServer's service layer is organized into functional modules that handle specific aspects of the platform. Each module encapsulates related functionality and provides a clear API for interaction with other parts of the system. This chapter describes each service module and its responsibilities within the overall architecture.
|
||||
botserver's service layer is organized into functional modules that handle specific aspects of the platform. Each module encapsulates related functionality and provides a clear API for interaction with other parts of the system. This chapter describes each service module and its responsibilities within the overall architecture.
|
||||
|
||||
|
||||
## Core Service Modules
|
||||
|
|
|
|||
|
|
@ -4,7 +4,7 @@ This chapter covers bot configuration through the `config.csv` file system. Each
|
|||
|
||||
## Configuration System
|
||||
|
||||
BotServer uses a straightforward name-value CSV format for configuration:
|
||||
botserver uses a straightforward name-value CSV format for configuration:
|
||||
|
||||
```csv
|
||||
name,value
|
||||
|
|
|
|||
|
|
@ -1,10 +1,10 @@
|
|||
# LLM Configuration
|
||||
|
||||
Configuration for Language Model integration in BotServer, supporting both local GGUF models and external API services.
|
||||
Configuration for Language Model integration in botserver, supporting both local GGUF models and external API services.
|
||||
|
||||
## Local Model Configuration
|
||||
|
||||
BotServer is designed to work with local GGUF models by default. The minimal configuration requires only a few settings in your `config.csv`:
|
||||
botserver is designed to work with local GGUF models by default. The minimal configuration requires only a few settings in your `config.csv`:
|
||||
|
||||
```csv
|
||||
llm-key,none
|
||||
|
|
@ -18,13 +18,13 @@ The `llm-model` parameter accepts relative paths like `../../../../data/llm/mode
|
|||
|
||||
### Supported Model Formats
|
||||
|
||||
BotServer supports GGUF quantized models for CPU and GPU inference. Quantization levels include Q3_K_M, Q4_K_M, and Q5_K_M for reduced memory usage with acceptable quality trade-offs, while F16 and F32 provide full precision for maximum quality.
|
||||
botserver supports GGUF quantized models for CPU and GPU inference. Quantization levels include Q3_K_M, Q4_K_M, and Q5_K_M for reduced memory usage with acceptable quality trade-offs, while F16 and F32 provide full precision for maximum quality.
|
||||
|
||||
## LLM Server Configuration
|
||||
|
||||
### Running Embedded Server
|
||||
|
||||
BotServer can run its own LLM server for local inference:
|
||||
botserver can run its own LLM server for local inference:
|
||||
|
||||
```csv
|
||||
llm-server,true
|
||||
|
|
@ -205,7 +205,7 @@ Memory errors require reducing resource consumption. Lower `llm-server-ctx-size`
|
|||
|
||||
### Connection Refused
|
||||
|
||||
Connection errors usually indicate server configuration issues. Verify `llm-server` is set to true if expecting BotServer to run the server. Check that the configured port is not already in use by another process. Ensure firewall rules allow connections on the specified port.
|
||||
Connection errors usually indicate server configuration issues. Verify `llm-server` is set to true if expecting botserver to run the server. Check that the configured port is not already in use by another process. Ensure firewall rules allow connections on the specified port.
|
||||
|
||||
## Best Practices
|
||||
|
||||
|
|
|
|||
|
|
@ -1,14 +1,14 @@
|
|||
# Drive Integration
|
||||
|
||||
The drive component provides S3-compatible object storage for BotServer, storing bot packages, documents, and user files.
|
||||
The drive component provides S3-compatible object storage for botserver, storing bot packages, documents, and user files.
|
||||
|
||||
## Overview
|
||||
|
||||
BotServer uses the drive component as its primary storage backend for bot packages in `.gbai` directories, knowledge base documents in `.gbkb` files, configuration files like `config.csv`, media and attachments, and user-uploaded content.
|
||||
botserver uses the drive component as its primary storage backend for bot packages in `.gbai` directories, knowledge base documents in `.gbkb` files, configuration files like `config.csv`, media and attachments, and user-uploaded content.
|
||||
|
||||
## Configuration
|
||||
|
||||
Storage configuration is automatically managed by the Directory service (Zitadel), so you do not need to configure storage credentials manually. During bootstrap, the Directory service provisions storage credentials, distributes them securely to BotServer, and handles credential rotation automatically.
|
||||
Storage configuration is automatically managed by the Directory service (Zitadel), so you do not need to configure storage credentials manually. During bootstrap, the Directory service provisions storage credentials, distributes them securely to botserver, and handles credential rotation automatically.
|
||||
|
||||
## Storage Structure
|
||||
|
||||
|
|
@ -22,7 +22,7 @@ Each bot gets its own bucket named after the bot package. The bucket naming conv
|
|||
|
||||
### Automatic Upload
|
||||
|
||||
When deploying a bot package, BotServer automatically creates a bucket if it doesn't exist, uploads all package files, maintains the directory structure, and preserves file permissions.
|
||||
When deploying a bot package, botserver automatically creates a bucket if it doesn't exist, uploads all package files, maintains the directory structure, and preserves file permissions.
|
||||
|
||||
### Real-time Synchronization
|
||||
|
||||
|
|
@ -34,7 +34,7 @@ The `DriveMonitor` service watches for changes in drive storage. It detects conf
|
|||
|
||||
## Bootstrap Integration
|
||||
|
||||
During bootstrap, BotServer handles installation by downloading and installing the drive binary if not present, receiving credentials from the Directory service, creating data directories, and uploading template files to drive storage.
|
||||
During bootstrap, botserver handles installation by downloading and installing the drive binary if not present, receiving credentials from the Directory service, creating data directories, and uploading template files to drive storage.
|
||||
|
||||
Knowledge base files are uploaded to drive buckets, indexed for vector search, and cached locally for improved performance.
|
||||
|
||||
|
|
@ -56,7 +56,7 @@ The built-in console provides a file browser for drive with paths like `/media/`
|
|||
|
||||
## S3-Compatible Client Configuration
|
||||
|
||||
BotServer uses an S3-compatible client configured for the drive:
|
||||
botserver uses an S3-compatible client configured for the drive:
|
||||
|
||||
```rust
|
||||
let config = S3Config::builder()
|
||||
|
|
@ -85,7 +85,7 @@ lxc config device add default-drive data disk \
|
|||
|
||||
### External S3-Compatible Storage
|
||||
|
||||
BotServer can use existing S3-compatible infrastructure. The Directory service manages the connection and supports providers including MinIO (the default local installation), Backblaze B2, Wasabi, DigitalOcean Spaces, Cloudflare R2, and any other S3-compatible service.
|
||||
botserver can use existing S3-compatible infrastructure. The Directory service manages the connection and supports providers including MinIO (the default local installation), Backblaze B2, Wasabi, DigitalOcean Spaces, Cloudflare R2, and any other S3-compatible service.
|
||||
|
||||
To use external storage, configure it through the Directory service admin console.
|
||||
|
||||
|
|
|
|||
|
|
@ -108,7 +108,7 @@ Note: Most service credentials (database, drive, cache) are fetched automaticall
|
|||
### At Startup
|
||||
|
||||
```
|
||||
1. BotServer starts
|
||||
1. botserver starts
|
||||
2. Reads .env for VAULT_ADDR and VAULT_TOKEN (only 2 variables)
|
||||
3. Connects to Vault
|
||||
4. Fetches ALL service credentials:
|
||||
|
|
@ -437,7 +437,7 @@ vault kv put gbo/llm \
|
|||
openai_key=sk-new-key \
|
||||
anthropic_key=sk-ant-new-key
|
||||
|
||||
# BotServer will pick up new keys automatically (cache TTL)
|
||||
# botserver will pick up new keys automatically (cache TTL)
|
||||
```
|
||||
|
||||
### 5. Backup Vault Data
|
||||
|
|
@ -491,7 +491,7 @@ tar -czf vault-backup.tar.gz botserver-stack/data/vault/
|
|||
│
|
||||
▼
|
||||
┌─────────────────────────────────────────────────────────────────┐
|
||||
│ BotServer │
|
||||
│ botserver │
|
||||
│ Connects to all services using Vault secrets │
|
||||
└─────────────────────────────┬───────────────────────────────────┘
|
||||
│
|
||||
|
|
|
|||
|
|
@ -1,6 +1,6 @@
|
|||
# Tool Compilation
|
||||
|
||||
BotServer compiles BASIC scripts (`.bas` files) into tool definitions that can be called by the LLM. The compilation process extracts parameters, descriptions, and generates metadata for tool discovery.
|
||||
botserver compiles BASIC scripts (`.bas` files) into tool definitions that can be called by the LLM. The compilation process extracts parameters, descriptions, and generates metadata for tool discovery.
|
||||
|
||||
## Overview
|
||||
|
||||
|
|
|
|||
|
|
@ -1,10 +1,10 @@
|
|||
# External APIs
|
||||
|
||||
BotServer enables integration with external APIs through BASIC scripts, allowing bots to connect with third-party services and extend functionality beyond built-in capabilities.
|
||||
botserver enables integration with external APIs through BASIC scripts, allowing bots to connect with third-party services and extend functionality beyond built-in capabilities.
|
||||
|
||||
## Overview
|
||||
|
||||
External API integration in BotServer is achieved through:
|
||||
External API integration in botserver is achieved through:
|
||||
- The `GET` keyword for HTTP/HTTPS requests
|
||||
- LLM function calling for API interactions
|
||||
- BASIC script logic for response processing
|
||||
|
|
@ -63,7 +63,7 @@ let data = GET url
|
|||
|
||||
### Bearer Token (via Headers)
|
||||
|
||||
Currently, BotServer's GET keyword doesn't support custom headers directly. For APIs requiring Bearer tokens or custom headers, you need to:
|
||||
Currently, botserver's GET keyword doesn't support custom headers directly. For APIs requiring Bearer tokens or custom headers, you need to:
|
||||
1. Use proxy endpoints that add authentication
|
||||
2. Or use APIs that support key-in-URL authentication
|
||||
|
||||
|
|
@ -255,4 +255,4 @@ TALK "Latest news: " + news
|
|||
|
||||
## Summary
|
||||
|
||||
While BotServer's external API capabilities are currently limited to GET requests, creative use of response processing and bot memory for state management enables integration with many third-party services. For more complex API interactions, consider using proxy services or custom integrations.
|
||||
While botserver's external API capabilities are currently limited to GET requests, creative use of response processing and bot memory for state management enables integration with many third-party services. For more complex API interactions, consider using proxy services or custom integrations.
|
||||
|
|
@ -1,6 +1,6 @@
|
|||
# GET Keyword Integration
|
||||
|
||||
The `GET` keyword in BotServer provides file retrieval capabilities from both local filesystem and drive (S3-compatible) storage, enabling tools to access documents, data files, and other resources.
|
||||
The `GET` keyword in botserver provides file retrieval capabilities from both local filesystem and drive (S3-compatible) storage, enabling tools to access documents, data files, and other resources.
|
||||
|
||||
## Overview
|
||||
|
||||
|
|
|
|||
|
|
@ -1,6 +1,6 @@
|
|||
# MCP Format
|
||||
|
||||
Model Context Protocol (MCP) is a standardized format for defining tools that language models can discover and invoke. BotServer generates MCP-compatible tool definitions from BASIC scripts.
|
||||
Model Context Protocol (MCP) is a standardized format for defining tools that language models can discover and invoke. botserver generates MCP-compatible tool definitions from BASIC scripts.
|
||||
|
||||
## Overview
|
||||
|
||||
|
|
@ -83,7 +83,7 @@ TALK "Processing order for " + customer_name
|
|||
|
||||
## Parameter Types
|
||||
|
||||
MCP supports these parameter types in BotServer:
|
||||
MCP supports these parameter types in botserver:
|
||||
|
||||
| BASIC Type | MCP Type | JSON Schema Type |
|
||||
|------------|----------|------------------|
|
||||
|
|
@ -190,7 +190,7 @@ MCP definitions are stored in the `basic_tools` table:
|
|||
4. **Discoverable**: LLMs can understand tool capabilities
|
||||
5. **Extensible**: Can add custom properties as needed
|
||||
|
||||
## Limitations in BotServer
|
||||
## Limitations in botserver
|
||||
|
||||
Current MCP implementation limitations:
|
||||
- No nested object parameters
|
||||
|
|
@ -217,4 +217,4 @@ MCP tools are validated during compilation:
|
|||
|
||||
## Summary
|
||||
|
||||
The MCP format provides a structured way to expose BASIC scripts as callable tools for LLMs. By generating MCP-compatible definitions, BotServer enables seamless tool discovery and invocation within conversational flows.
|
||||
The MCP format provides a structured way to expose BASIC scripts as callable tools for LLMs. By generating MCP-compatible definitions, botserver enables seamless tool discovery and invocation within conversational flows.
|
||||
|
|
@ -1,6 +1,6 @@
|
|||
# NVIDIA GPU Setup for LXC Containers
|
||||
|
||||
This guide covers setting up NVIDIA GPU passthrough for BotServer running in LXC containers, enabling hardware acceleration for local LLM inference.
|
||||
This guide covers setting up NVIDIA GPU passthrough for botserver running in LXC containers, enabling hardware acceleration for local LLM inference.
|
||||
|
||||
## Prerequisites
|
||||
|
||||
|
|
@ -111,7 +111,7 @@ nvidia-smi
|
|||
# Should show your GPU with driver version 560.35.05
|
||||
```
|
||||
|
||||
## Configure BotServer for GPU
|
||||
## Configure botserver for GPU
|
||||
|
||||
Update your bot's `config.csv` to use GPU acceleration:
|
||||
|
||||
|
|
@ -232,7 +232,7 @@ cmake .. -DLLAMA_F16C=ON
|
|||
### After Compilation
|
||||
|
||||
```bash
|
||||
# Copy compiled binary to BotServer
|
||||
# Copy compiled binary to botserver
|
||||
cp bin/llama-server /path/to/botserver-stack/bin/llm/
|
||||
|
||||
# Update config.csv to use custom build
|
||||
|
|
@ -282,6 +282,6 @@ With GPU acceleration enabled:
|
|||
|
||||
## Next Steps
|
||||
|
||||
- [Installation Guide](./installation.md) - Complete BotServer setup
|
||||
- [Installation Guide](./installation.md) - Complete botserver setup
|
||||
- [Quick Start](./quick-start.md) - Create your first bot
|
||||
- [Configuration Reference](../chapter-02/gbot.md) - All GPU-related parameters
|
||||
|
|
@ -1,6 +1,6 @@
|
|||
# Tool Format
|
||||
|
||||
BotServer generates OpenAI-compatible function definitions from BASIC scripts, enabling integration with OpenAI's function calling API.
|
||||
botserver generates OpenAI-compatible function definitions from BASIC scripts, enabling integration with OpenAI's function calling API.
|
||||
|
||||
## Overview
|
||||
|
||||
|
|
@ -111,7 +111,7 @@ When using OpenAI's API, the functions are passed in the request:
|
|||
2. **Function Discovery**: GPT identifies relevant function
|
||||
3. **Parameter Extraction**: GPT extracts parameters from context
|
||||
4. **Function Call**: GPT generates structured function call
|
||||
5. **Execution**: BotServer executes the BASIC script
|
||||
5. **Execution**: botserver executes the BASIC script
|
||||
6. **Result Processing**: Output returned to GPT for response
|
||||
|
||||
## Example Function Calls
|
||||
|
|
@ -202,7 +202,7 @@ Function errors are handled gracefully:
|
|||
|
||||
## Limitations
|
||||
|
||||
Current OpenAI format limitations in BotServer:
|
||||
Current OpenAI format limitations in botserver:
|
||||
- No nested objects in parameters
|
||||
- No array parameters
|
||||
- No enum constraints
|
||||
|
|
@ -249,4 +249,4 @@ To debug OpenAI function calls:
|
|||
|
||||
## Summary
|
||||
|
||||
The OpenAI function format enables seamless integration between BASIC scripts and OpenAI's GPT models. By automatically generating compatible function definitions, BotServer allows natural language interactions to trigger complex business logic implementations.
|
||||
The OpenAI function format enables seamless integration between BASIC scripts and OpenAI's GPT models. By automatically generating compatible function definitions, botserver allows natural language interactions to trigger complex business logic implementations.
|
||||
|
|
@ -1,6 +1,6 @@
|
|||
# Tool Definition
|
||||
|
||||
In BotServer, a **tool** is simply a `.bas` file. That's it!
|
||||
In botserver, a **tool** is simply a `.bas` file. That's it!
|
||||
|
||||
## How It Works
|
||||
|
||||
|
|
@ -148,7 +148,7 @@ TALK "I can help with various tasks. What do you need?"
|
|||
|
||||
## Tool Format Conversion
|
||||
|
||||
BotServer automatically converts your `.bas` tools to:
|
||||
botserver automatically converts your `.bas` tools to:
|
||||
|
||||
- **MCP (Model Context Protocol)** format
|
||||
- **Groq/OpenAI-compatible function calling** format
|
||||
|
|
|
|||
|
|
@ -1,10 +1,10 @@
|
|||
# Chapter 10: REST Endpoints
|
||||
|
||||
HTTP API endpoints for integrating with BotServer.
|
||||
HTTP API endpoints for integrating with botserver.
|
||||
|
||||
## Overview
|
||||
|
||||
BotServer exposes REST endpoints organized by functional area. All endpoints follow consistent patterns for authentication, pagination, and error handling.
|
||||
botserver exposes REST endpoints organized by functional area. All endpoints follow consistent patterns for authentication, pagination, and error handling.
|
||||
|
||||
## Base URL
|
||||
|
||||
|
|
|
|||
|
|
@ -21,7 +21,7 @@ http://localhost:8080/api/v1/admin
|
|||
|
||||
## Authentication
|
||||
|
||||
Will use the standard BotServer authentication mechanism with administrator-level permissions required.
|
||||
Will use the standard botserver authentication mechanism with administrator-level permissions required.
|
||||
|
||||
## Endpoints (Planned)
|
||||
|
||||
|
|
|
|||
|
|
@ -21,7 +21,7 @@ http://localhost:8080/api/v1/ai
|
|||
|
||||
## Authentication
|
||||
|
||||
Will use the standard BotServer authentication mechanism with appropriate role-based permissions.
|
||||
Will use the standard botserver authentication mechanism with appropriate role-based permissions.
|
||||
|
||||
## Endpoints (Planned)
|
||||
|
||||
|
|
|
|||
|
|
@ -21,7 +21,7 @@ http://localhost:8080/api/v1/analytics
|
|||
|
||||
## Authentication
|
||||
|
||||
Will use the standard BotServer authentication mechanism with appropriate role-based permissions.
|
||||
Will use the standard botserver authentication mechanism with appropriate role-based permissions.
|
||||
|
||||
## Endpoints (Planned)
|
||||
|
||||
|
|
|
|||
|
|
@ -20,7 +20,7 @@ http://localhost:8080/api/v1/backup
|
|||
|
||||
## Authentication
|
||||
|
||||
Will use the standard BotServer authentication mechanism with appropriate role-based permissions.
|
||||
Will use the standard botserver authentication mechanism with appropriate role-based permissions.
|
||||
|
||||
## Endpoints (Planned)
|
||||
|
||||
|
|
|
|||
|
|
@ -1,12 +1,12 @@
|
|||
# Calendar API
|
||||
|
||||
The Calendar API provides endpoints for managing events, schedules, and time-based activities within BotServer.
|
||||
The Calendar API provides endpoints for managing events, schedules, and time-based activities within botserver.
|
||||
|
||||
## Status
|
||||
|
||||
**⚠️ NOT IMPLEMENTED**
|
||||
|
||||
This API is planned for future development but is not currently available in BotServer.
|
||||
This API is planned for future development but is not currently available in botserver.
|
||||
|
||||
## Planned Features
|
||||
|
||||
|
|
|
|||
|
|
@ -1,12 +1,12 @@
|
|||
# Calls API
|
||||
|
||||
The Calls API provides endpoints for managing voice and video calls, conference rooms, and real-time communication within BotServer.
|
||||
The Calls API provides endpoints for managing voice and video calls, conference rooms, and real-time communication within botserver.
|
||||
|
||||
## Status
|
||||
|
||||
**⚠️ NOT IMPLEMENTED**
|
||||
|
||||
This API is planned for future development but is not currently available in BotServer.
|
||||
This API is planned for future development but is not currently available in botserver.
|
||||
|
||||
## Planned Features
|
||||
|
||||
|
|
|
|||
|
|
@ -23,7 +23,7 @@ http://localhost:8080/api/v1/compliance
|
|||
|
||||
## Authentication
|
||||
|
||||
Will use the standard BotServer authentication mechanism with appropriate role-based permissions.
|
||||
Will use the standard botserver authentication mechanism with appropriate role-based permissions.
|
||||
|
||||
## Endpoints (Planned)
|
||||
|
||||
|
|
|
|||
|
|
@ -1,6 +1,6 @@
|
|||
# Document Processing API
|
||||
|
||||
BotServer provides RESTful endpoints for processing, extracting, and analyzing various document formats including PDFs, Office documents, and images.
|
||||
botserver provides RESTful endpoints for processing, extracting, and analyzing various document formats including PDFs, Office documents, and images.
|
||||
|
||||
## Overview
|
||||
|
||||
|
|
|
|||
|
|
@ -1,6 +1,6 @@
|
|||
# API Examples
|
||||
|
||||
This section provides practical examples of using the BotServer REST API in various programming languages and scenarios.
|
||||
This section provides practical examples of using the botserver REST API in various programming languages and scenarios.
|
||||
|
||||
## Authentication Examples
|
||||
|
||||
|
|
@ -406,7 +406,7 @@ describe('Groups API', () => {
|
|||
|
||||
## Summary
|
||||
|
||||
These examples demonstrate common patterns for interacting with the BotServer API. Remember to:
|
||||
These examples demonstrate common patterns for interacting with the botserver API. Remember to:
|
||||
- Handle authentication properly through Zitadel
|
||||
- Check response status codes
|
||||
- Parse error responses
|
||||
|
|
|
|||
|
|
@ -1,6 +1,6 @@
|
|||
# Group Membership API
|
||||
|
||||
BotServer provides RESTful endpoints for managing user groups, team memberships, and collaborative workspaces.
|
||||
botserver provides RESTful endpoints for managing user groups, team memberships, and collaborative workspaces.
|
||||
|
||||
## Overview
|
||||
|
||||
|
|
|
|||
|
|
@ -4,7 +4,7 @@ The Groups API provides endpoints for managing groups and organizations through
|
|||
|
||||
## Overview
|
||||
|
||||
Groups in BotServer represent organizations in Zitadel. They provide multi-tenant support and user grouping capabilities.
|
||||
Groups in botserver represent organizations in Zitadel. They provide multi-tenant support and user grouping capabilities.
|
||||
|
||||
## Endpoints
|
||||
|
||||
|
|
@ -170,7 +170,7 @@ All group operations are proxied to Zitadel:
|
|||
|
||||
### Data Model
|
||||
|
||||
Groups are not stored in BotServer's database. All data comes from Zitadel:
|
||||
Groups are not stored in botserver's database. All data comes from Zitadel:
|
||||
- Group metadata from Zitadel orgs
|
||||
- Membership from Zitadel org members
|
||||
- Permissions from Zitadel policies
|
||||
|
|
|
|||
|
|
@ -22,7 +22,7 @@ http://localhost:8080/api/v1/ml
|
|||
|
||||
## Authentication
|
||||
|
||||
Will use the standard BotServer authentication mechanism with appropriate role-based permissions.
|
||||
Will use the standard botserver authentication mechanism with appropriate role-based permissions.
|
||||
|
||||
## Endpoints (Planned)
|
||||
|
||||
|
|
|
|||
|
|
@ -22,7 +22,7 @@ http://localhost:8080/api/v1/monitoring
|
|||
|
||||
## Authentication
|
||||
|
||||
Will use the standard BotServer authentication mechanism with appropriate role-based permissions.
|
||||
Will use the standard botserver authentication mechanism with appropriate role-based permissions.
|
||||
|
||||
## Endpoints (Planned)
|
||||
|
||||
|
|
|
|||
|
|
@ -1,6 +1,6 @@
|
|||
# Notifications API
|
||||
|
||||
BotServer provides RESTful endpoints for managing notifications across multiple channels including push notifications, in-app alerts, and message broadcasting.
|
||||
botserver provides RESTful endpoints for managing notifications across multiple channels including push notifications, in-app alerts, and message broadcasting.
|
||||
|
||||
## Overview
|
||||
|
||||
|
|
@ -274,7 +274,7 @@ Send notification using a template.
|
|||
"template": "welcome_message",
|
||||
"recipients": ["user789"],
|
||||
"variables": {
|
||||
"app_name": "BotServer",
|
||||
"app_name": "botserver",
|
||||
"user_name": "John"
|
||||
}
|
||||
}
|
||||
|
|
|
|||
|
|
@ -21,7 +21,7 @@ http://localhost:8080/api/v1/reports
|
|||
|
||||
## Authentication
|
||||
|
||||
Will use the standard BotServer authentication mechanism with appropriate role-based permissions.
|
||||
Will use the standard botserver authentication mechanism with appropriate role-based permissions.
|
||||
|
||||
## Endpoints (Planned)
|
||||
|
||||
|
|
|
|||
|
|
@ -23,7 +23,7 @@ http://localhost:8080/api/v1/security
|
|||
|
||||
## Authentication
|
||||
|
||||
Will use the standard BotServer authentication mechanism with elevated security permissions required.
|
||||
Will use the standard botserver authentication mechanism with elevated security permissions required.
|
||||
|
||||
## Endpoints (Planned)
|
||||
|
||||
|
|
|
|||
|
|
@ -2,7 +2,7 @@
|
|||
|
||||
> *⚠️ Note: This API is not yet implemented and is planned for a future release.*
|
||||
|
||||
BotServer provides a RESTful API for managing file storage and object management through its S3-compatible storage backend.
|
||||
botserver provides a RESTful API for managing file storage and object management through its S3-compatible storage backend.
|
||||
|
||||
## Overview
|
||||
|
||||
|
|
|
|||
|
|
@ -1,6 +1,6 @@
|
|||
# Tasks API
|
||||
|
||||
BotServer provides RESTful endpoints for creating, managing, and tracking tasks and workflows within bot conversations.
|
||||
botserver provides RESTful endpoints for creating, managing, and tracking tasks and workflows within bot conversations.
|
||||
|
||||
## Overview
|
||||
|
||||
|
|
|
|||
|
|
@ -1,6 +1,6 @@
|
|||
# User Security API
|
||||
|
||||
BotServer provides RESTful endpoints for user management, authentication, authorization, and security features.
|
||||
botserver provides RESTful endpoints for user management, authentication, authorization, and security features.
|
||||
|
||||
## Overview
|
||||
|
||||
|
|
|
|||
|
|
@ -1,13 +1,13 @@
|
|||
# Users API
|
||||
|
||||
The Users API provides endpoints for user management operations. User authentication is handled through Zitadel, with BotServer maintaining session associations and user preferences.
|
||||
The Users API provides endpoints for user management operations. User authentication is handled through Zitadel, with botserver maintaining session associations and user preferences.
|
||||
|
||||
## Overview
|
||||
|
||||
User management in General Bots follows a federated model:
|
||||
|
||||
- **Zitadel**: Primary identity provider (authentication, SSO, user creation)
|
||||
- **BotServer**: Session management, preferences, bot-specific user data
|
||||
- **botserver**: Session management, preferences, bot-specific user data
|
||||
|
||||
## Endpoints
|
||||
|
||||
|
|
@ -367,7 +367,7 @@ For full user management, access Zitadel admin console:
|
|||
|
||||
## Database Schema
|
||||
|
||||
BotServer maintains minimal user data:
|
||||
botserver maintains minimal user data:
|
||||
|
||||
```sql
|
||||
-- users table (synced from Zitadel)
|
||||
|
|
|
|||
|
|
@ -1,16 +1,16 @@
|
|||
# Whiteboard API
|
||||
|
||||
The Whiteboard API provides endpoints for collaborative drawing, diagramming, and visual collaboration within BotServer.
|
||||
The Whiteboard API provides endpoints for collaborative drawing, diagramming, and visual collaboration within botserver.
|
||||
|
||||
## Status
|
||||
|
||||
**⚠️ NOT IMPLEMENTED**
|
||||
|
||||
This API is planned for future development but is not currently available in BotServer.
|
||||
This API is planned for future development but is not currently available in botserver.
|
||||
|
||||
## Planned Features
|
||||
|
||||
The Whiteboard API will enable collaborative real-time drawing, shape and diagram creation, text annotations, image uploads, multi-user cursors, version history, and export capabilities. These features will provide teams with a complete visual collaboration environment integrated directly into the BotServer platform.
|
||||
The Whiteboard API will enable collaborative real-time drawing, shape and diagram creation, text annotations, image uploads, multi-user cursors, version history, and export capabilities. These features will provide teams with a complete visual collaboration environment integrated directly into the botserver platform.
|
||||
|
||||
## Planned Endpoints
|
||||
|
||||
|
|
|
|||
|
|
@ -1,11 +1,11 @@
|
|||
# AI and LLM
|
||||
|
||||
BotServer integrates with Large Language Models to provide intelligent conversational capabilities and natural language understanding. This integration forms the core of what makes General Bots conversations feel natural and contextually aware.
|
||||
botserver integrates with Large Language Models to provide intelligent conversational capabilities and natural language understanding. This integration forms the core of what makes General Bots conversations feel natural and contextually aware.
|
||||
|
||||
|
||||
## Overview
|
||||
|
||||
The LLM integration in BotServer enables sophisticated conversational experiences. Natural language conversations flow smoothly without rigid command structures. Responses are context-aware, drawing on conversation history and loaded knowledge bases. The system automatically discovers and invokes tools when they would help answer user questions. Document understanding allows bots to read and reason about uploaded files. Text generation and summarization capabilities support content creation and information distillation.
|
||||
The LLM integration in botserver enables sophisticated conversational experiences. Natural language conversations flow smoothly without rigid command structures. Responses are context-aware, drawing on conversation history and loaded knowledge bases. The system automatically discovers and invokes tools when they would help answer user questions. Document understanding allows bots to read and reason about uploaded files. Text generation and summarization capabilities support content creation and information distillation.
|
||||
|
||||
|
||||
## LLM Providers
|
||||
|
|
@ -23,7 +23,7 @@ LLM_MODEL=gpt-5
|
|||
|
||||
### Local Models
|
||||
|
||||
For privacy-sensitive deployments or cost control, BotServer supports self-hosted models. Llama.cpp compatible servers provide open-source model hosting. Custom inference endpoints allow integration with any API-compatible service. Privacy-preserving deployments keep all data on-premises without external API calls.
|
||||
For privacy-sensitive deployments or cost control, botserver supports self-hosted models. Llama.cpp compatible servers provide open-source model hosting. Custom inference endpoints allow integration with any API-compatible service. Privacy-preserving deployments keep all data on-premises without external API calls.
|
||||
|
||||
Configuration for local models specifies the provider type and endpoint:
|
||||
|
||||
|
|
@ -186,7 +186,7 @@ GPT-5 mini offers the fastest responses at the lowest cost, suitable for straigh
|
|||
|
||||
## Integration with Tools
|
||||
|
||||
LLMs in BotServer work closely with the tool system. The model receives tool definitions describing available functions. When a user request would benefit from tool use, the model generates a tool call. BotServer executes the tool and returns results to the model. The model incorporates tool results into its final response.
|
||||
LLMs in botserver work closely with the tool system. The model receives tool definitions describing available functions. When a user request would benefit from tool use, the model generates a tool call. botserver executes the tool and returns results to the model. The model incorporates tool results into its final response.
|
||||
|
||||
This integration enables bots to take actions beyond conversation, such as querying databases, sending emails, or calling external APIs, all orchestrated naturally through conversation.
|
||||
|
||||
|
|
|
|||
|
|
@ -1,10 +1,10 @@
|
|||
# Automation
|
||||
|
||||
This chapter explains how BotServer enables bots to perform scheduled and event-driven tasks without requiring direct user interaction. Through automation capabilities, bots can proactively maintain content, process data, and respond to system events, transforming them from reactive assistants into active participants in organizational workflows.
|
||||
This chapter explains how botserver enables bots to perform scheduled and event-driven tasks without requiring direct user interaction. Through automation capabilities, bots can proactively maintain content, process data, and respond to system events, transforming them from reactive assistants into active participants in organizational workflows.
|
||||
|
||||
## Automation Fundamentals
|
||||
|
||||
BotServer implements automation through two complementary mechanisms. The SET SCHEDULE keyword enables cron-based task scheduling, allowing scripts to execute at predetermined times. Event triggers through the ON keyword enable scripts to respond to database changes and system events. Together, these mechanisms support a wide range of automation scenarios from simple periodic tasks to complex event-driven workflows.
|
||||
botserver implements automation through two complementary mechanisms. The SET SCHEDULE keyword enables cron-based task scheduling, allowing scripts to execute at predetermined times. Event triggers through the ON keyword enable scripts to respond to database changes and system events. Together, these mechanisms support a wide range of automation scenarios from simple periodic tasks to complex event-driven workflows.
|
||||
|
||||
Understanding when to use automation is as important as understanding how. Automated tasks run without an active user session, which means they cannot directly communicate with users through TALK statements. Instead, automated scripts typically gather and process information, storing results in bot memory where users can access it during their next interaction.
|
||||
|
||||
|
|
@ -108,4 +108,4 @@ Monitoring for runaway automation helps catch scripts that behave differently th
|
|||
|
||||
## Summary
|
||||
|
||||
BotServer's automation capabilities transform bots from reactive assistants into proactive system participants. Through SET SCHEDULE and event triggers, bots can maintain fresh content, process data regularly, and respond to system events without user interaction. Understanding the automation lifecycle, limitations, and best practices enables effective use of these powerful capabilities while avoiding common pitfalls. Automation extends bot value by handling routine tasks automatically, freeing users to focus on work that requires human judgment.
|
||||
botserver's automation capabilities transform bots from reactive assistants into proactive system participants. Through SET SCHEDULE and event triggers, bots can maintain fresh content, process data regularly, and respond to system events without user interaction. Understanding the automation lifecycle, limitations, and best practices enables effective use of these powerful capabilities while avoiding common pitfalls. Automation extends bot value by handling routine tasks automatically, freeing users to focus on work that requires human judgment.
|
||||
|
|
@ -1,10 +1,10 @@
|
|||
# Multi-Channel Support
|
||||
|
||||
This chapter describes how BotServer enables bots to communicate with users across different platforms through its flexible multi-channel architecture. The design ensures that conversation logic remains consistent regardless of how users choose to interact, while still taking advantage of each channel's unique capabilities.
|
||||
This chapter describes how botserver enables bots to communicate with users across different platforms through its flexible multi-channel architecture. The design ensures that conversation logic remains consistent regardless of how users choose to interact, while still taking advantage of each channel's unique capabilities.
|
||||
|
||||
## Architectural Foundation
|
||||
|
||||
BotServer abstracts communication methods through a channel adapter pattern that separates bot logic from platform-specific details. When a user sends a message, it flows from their chosen platform through a channel adapter that converts the platform-specific format into a common message structure. The bot processes this message, generates a response, and the adapter converts it back to the appropriate format for delivery.
|
||||
botserver abstracts communication methods through a channel adapter pattern that separates bot logic from platform-specific details. When a user sends a message, it flows from their chosen platform through a channel adapter that converts the platform-specific format into a common message structure. The bot processes this message, generates a response, and the adapter converts it back to the appropriate format for delivery.
|
||||
|
||||
This abstraction provides significant benefits for bot development. The same BASIC scripts work across all supported channels without modification. Conversation state persists even when users switch between platforms. New channels can be added without changing existing bot logic.
|
||||
|
||||
|
|
@ -20,7 +20,7 @@ The implementation handles WebSocket connection management, maintaining long-liv
|
|||
|
||||
## Voice Interaction
|
||||
|
||||
When the voice feature is enabled, BotServer supports spoken interaction through speech-to-text and text-to-speech processing. Voice conversations follow a continuous flow where the system listens for user speech, converts it to text, processes it through the same BASIC scripts used for text channels, and converts the response back to speech for playback.
|
||||
When the voice feature is enabled, botserver supports spoken interaction through speech-to-text and text-to-speech processing. Voice conversations follow a continuous flow where the system listens for user speech, converts it to text, processes it through the same BASIC scripts used for text channels, and converts the response back to speech for playback.
|
||||
|
||||
This channel requires integration with speech services and is optional due to its additional infrastructure requirements. Organizations that enable voice interaction can serve users who prefer speaking to typing or who are in situations where hands-free operation is beneficial.
|
||||
|
||||
|
|
@ -86,4 +86,4 @@ Monitoring channel metrics helps identify performance issues or user experience
|
|||
|
||||
## Summary
|
||||
|
||||
BotServer's multi-channel architecture enables bots to reach users wherever they prefer to communicate while maintaining consistent conversation logic and state. The channel adapter pattern isolates platform-specific concerns from bot development, allowing the same scripts to work across current channels and future integrations. This design philosophy prioritizes developer productivity and user experience across an expanding communication landscape.
|
||||
botserver's multi-channel architecture enables bots to reach users wherever they prefer to communicate while maintaining consistent conversation logic and state. The channel adapter pattern isolates platform-specific concerns from bot development, allowing the same scripts to work across current channels and future integrations. This design philosophy prioritizes developer productivity and user experience across an expanding communication landscape.
|
||||
|
|
@ -1,10 +1,10 @@
|
|||
# Conversation Management
|
||||
|
||||
This chapter explores how BotServer manages conversations through sessions, message history, and context tracking. Understanding these mechanisms helps you build bots that maintain coherent, contextual interactions across multiple turns and sessions.
|
||||
This chapter explores how botserver manages conversations through sessions, message history, and context tracking. Understanding these mechanisms helps you build bots that maintain coherent, contextual interactions across multiple turns and sessions.
|
||||
|
||||
## The Conversation Lifecycle
|
||||
|
||||
Every conversation in BotServer follows a well-defined lifecycle that begins when a user first connects and continues until the session expires or ends explicitly. When a user interacts with a bot, the system creates a session that serves as the container for all conversation state, including message history, user preferences, and any variables set during the interaction.
|
||||
Every conversation in botserver follows a well-defined lifecycle that begins when a user first connects and continues until the session expires or ends explicitly. When a user interacts with a bot, the system creates a session that serves as the container for all conversation state, including message history, user preferences, and any variables set during the interaction.
|
||||
|
||||
Sessions persist across individual messages, allowing conversations to span multiple interactions. A user might ask a question, receive a response, and return hours later to continue the same conversation thread. The system maintains this continuity by storing session data in PostgreSQL for durability while caching active sessions in the cache layer for fast access.
|
||||
|
||||
|
|
@ -30,7 +30,7 @@ Scripts can manipulate context directly through dedicated keywords. Setting cont
|
|||
|
||||
## Multi-Turn Interaction Patterns
|
||||
|
||||
Conversations rarely consist of single isolated exchanges. Users ask follow-up questions, refine requests, and reference earlier parts of the conversation. BotServer's architecture specifically supports these multi-turn patterns through careful context management and entity tracking.
|
||||
Conversations rarely consist of single isolated exchanges. Users ask follow-up questions, refine requests, and reference earlier parts of the conversation. botserver's architecture specifically supports these multi-turn patterns through careful context management and entity tracking.
|
||||
|
||||
When a user says "Book a meeting for tomorrow" followed by "Make it at 2 PM," the system must understand that "it" refers to the meeting mentioned in the previous turn. This reference resolution happens automatically through the included conversation history, which gives the model the context needed to interpret pronouns and implicit references correctly.
|
||||
|
||||
|
|
@ -40,7 +40,7 @@ Guided conversations implement multi-step flows where the bot collects informati
|
|||
|
||||
## Session Recovery and Continuity
|
||||
|
||||
Network interruptions, browser refreshes, and other disruptions shouldn't break conversation flow. BotServer implements robust session recovery that allows users to seamlessly continue where they left off.
|
||||
Network interruptions, browser refreshes, and other disruptions shouldn't break conversation flow. botserver implements robust session recovery that allows users to seamlessly continue where they left off.
|
||||
|
||||
When a user reconnects, the session identifier validates their return. The system retrieves stored history and reconstructs the conversation context. The user can then continue as if no interruption occurred, with full access to previous exchanges and accumulated state.
|
||||
|
||||
|
|
@ -48,7 +48,7 @@ Error recovery extends beyond simple disconnections. If a response generation fa
|
|||
|
||||
## Anonymous and Authenticated Conversations
|
||||
|
||||
BotServer supports both authenticated users and anonymous visitors, with different handling for each case. Understanding these distinctions helps design appropriate conversation experiences.
|
||||
botserver supports both authenticated users and anonymous visitors, with different handling for each case. Understanding these distinctions helps design appropriate conversation experiences.
|
||||
|
||||
Anonymous sessions receive temporary identifiers that exist only for the duration of the session. Permissions are limited compared to authenticated users. Storage is typically short-term, with sessions expiring quickly after inactivity. These constraints reflect the reduced trust level for unidentified users.
|
||||
|
||||
|
|
@ -64,7 +64,7 @@ Messages follow a structured format with type identifiers, content payloads, and
|
|||
|
||||
## Conversation Analytics
|
||||
|
||||
Understanding how conversations perform helps improve bot effectiveness. BotServer tracks numerous metrics that reveal conversation patterns and quality indicators.
|
||||
Understanding how conversations perform helps improve bot effectiveness. botserver tracks numerous metrics that reveal conversation patterns and quality indicators.
|
||||
|
||||
Quantitative metrics include message counts, conversation lengths, response times, and tool usage frequency. These numbers identify basic patterns like peak usage times and average conversation depth.
|
||||
|
||||
|
|
@ -82,7 +82,7 @@ These settings balance resource usage against conversation quality and complianc
|
|||
|
||||
## Privacy and Compliance
|
||||
|
||||
Conversation data represents sensitive information that requires careful handling. BotServer implements multiple safeguards to protect user privacy while meeting compliance requirements.
|
||||
Conversation data represents sensitive information that requires careful handling. botserver implements multiple safeguards to protect user privacy while meeting compliance requirements.
|
||||
|
||||
Data retention policies ensure information doesn't persist longer than necessary. Compression and archival reduce storage costs while maintaining accessibility for compliance purposes. Clear deletion procedures support user rights to have their data removed.
|
||||
|
||||
|
|
@ -90,4 +90,4 @@ Access controls limit who can view conversation history. Users see their own con
|
|||
|
||||
## Summary
|
||||
|
||||
Conversation management in BotServer provides the foundation for meaningful bot interactions. Through careful session handling, comprehensive message history, sophisticated context assembly, and robust recovery mechanisms, the system enables conversations that feel natural and maintain coherence across multiple turns, sessions, and circumstances. Understanding these capabilities helps developers build bots that engage users effectively while respecting privacy and compliance requirements.
|
||||
Conversation management in botserver provides the foundation for meaningful bot interactions. Through careful session handling, comprehensive message history, sophisticated context assembly, and robust recovery mechanisms, the system enables conversations that feel natural and maintain coherence across multiple turns, sessions, and circumstances. Understanding these capabilities helps developers build bots that engage users effectively while respecting privacy and compliance requirements.
|
||||
|
|
@ -1,6 +1,6 @@
|
|||
# Core Features
|
||||
|
||||
Technical overview of BotServer capabilities. For the complete feature matrix, see [Feature Reference](./README.md).
|
||||
Technical overview of botserver capabilities. For the complete feature matrix, see [Feature Reference](./README.md).
|
||||
|
||||
## Multi-Channel Communication
|
||||
|
||||
|
|
|
|||
|
|
@ -1,10 +1,10 @@
|
|||
# Email Integration
|
||||
|
||||
BotServer provides email integration capabilities through IMAP/SMTP protocols, allowing bots to read, send, and manage emails.
|
||||
botserver provides email integration capabilities through IMAP/SMTP protocols, allowing bots to read, send, and manage emails.
|
||||
|
||||
## Overview
|
||||
|
||||
Email integration in BotServer enables reading emails via IMAP, sending emails via SMTP, email account management, draft creation and management, folder organization, and email-based automation workflows.
|
||||
Email integration in botserver enables reading emails via IMAP, sending emails via SMTP, email account management, draft creation and management, folder organization, and email-based automation workflows.
|
||||
|
||||
## Configuration
|
||||
|
||||
|
|
@ -176,7 +176,7 @@ Provider-specific rate limits apply to all email operations. Implement delays be
|
|||
|
||||
### Gmail Configuration
|
||||
|
||||
To configure Gmail, first enable 2-factor authentication on your Google account. Then generate an app-specific password for BotServer to use. Enable IMAP access in Gmail settings. Use `imap.gmail.com` on port 993 for IMAP and `smtp.gmail.com` on port 587 for SMTP.
|
||||
To configure Gmail, first enable 2-factor authentication on your Google account. Then generate an app-specific password for botserver to use. Enable IMAP access in Gmail settings. Use `imap.gmail.com` on port 993 for IMAP and `smtp.gmail.com` on port 587 for SMTP.
|
||||
|
||||
### Outlook/Office 365
|
||||
|
||||
|
|
@ -221,4 +221,4 @@ Regular health checks should verify IMAP connectivity, SMTP availability, accoun
|
|||
|
||||
## Summary
|
||||
|
||||
Email integration in BotServer enables powerful email-based automation and communication. Through IMAP/SMTP protocols and BASIC script integration, bots can manage email workflows, automate responses, and integrate email with other bot features for comprehensive communication automation.
|
||||
Email integration in botserver enables powerful email-based automation and communication. Through IMAP/SMTP protocols and BASIC script integration, bots can manage email workflows, automate responses, and integrate email with other bot features for comprehensive communication automation.
|
||||
|
|
@ -1,10 +1,10 @@
|
|||
# Storage and Data
|
||||
|
||||
This chapter explains how BotServer organizes and manages data across its multiple storage layers. Understanding this architecture helps you make informed decisions about where to store different types of information and how to optimize storage performance for your deployment.
|
||||
This chapter explains how botserver organizes and manages data across its multiple storage layers. Understanding this architecture helps you make informed decisions about where to store different types of information and how to optimize storage performance for your deployment.
|
||||
|
||||
## Understanding the Storage Architecture
|
||||
|
||||
BotServer employs a multi-layered storage architecture where each layer serves specific purposes and data types. Rather than forcing all data into a single storage system, this design allows each component to use the storage technology best suited to its access patterns and requirements.
|
||||
botserver employs a multi-layered storage architecture where each layer serves specific purposes and data types. Rather than forcing all data into a single storage system, this design allows each component to use the storage technology best suited to its access patterns and requirements.
|
||||
|
||||
PostgreSQL serves as the primary database for all structured data, including user accounts, session information, bot configurations, and message history. Its relational model excels at maintaining data integrity and supporting complex queries across related entities.
|
||||
|
||||
|
|
@ -66,7 +66,7 @@ Automatic cleanup processes remove files that no longer serve purposes. Old temp
|
|||
|
||||
## Data Persistence and Backup
|
||||
|
||||
Reliable data storage requires comprehensive backup strategies that protect against various failure modes. BotServer's multi-layer architecture requires coordinating backups across storage systems.
|
||||
Reliable data storage requires comprehensive backup strategies that protect against various failure modes. botserver's multi-layer architecture requires coordinating backups across storage systems.
|
||||
|
||||
PostgreSQL backups capture the authoritative state of all structured data. Daily dumps create recovery points. Point-in-time recovery capabilities protect against accidental data modifications. Backup verification ensures that recovery would actually work when needed.
|
||||
|
||||
|
|
@ -88,7 +88,7 @@ Data security spans all storage layers with appropriate protections for each. En
|
|||
|
||||
Access control ensures users and processes only reach data they're authorized to access. Role-based permissions govern database operations. Bucket policies control object storage access. Bot isolation prevents cross-bot data leakage. Audit logging creates accountability trails for sensitive operations.
|
||||
|
||||
Sensitive data receives additional protection. Passwords never store in BotServer systems since Zitadel handles authentication. API keys and secrets encrypt with AES-GCM before storage. Personally identifiable information follows data protection regulations applicable to the deployment jurisdiction.
|
||||
Sensitive data receives additional protection. Passwords never store in botserver systems since Zitadel handles authentication. API keys and secrets encrypt with AES-GCM before storage. Personally identifiable information follows data protection regulations applicable to the deployment jurisdiction.
|
||||
|
||||
## Monitoring and Maintenance
|
||||
|
||||
|
|
@ -108,4 +108,4 @@ Connection failures require systematic investigation. Service status checks conf
|
|||
|
||||
## Summary
|
||||
|
||||
BotServer's storage architecture distributes data across specialized systems optimized for different access patterns. PostgreSQL handles structured data with transactional integrity. Drive provides scalable object storage for files and documents. Valkey accelerates access to frequently used information. Qdrant enables semantic search through vector storage. Understanding this architecture helps you configure storage appropriately, implement effective backup strategies, and troubleshoot issues when they arise. The result is a storage foundation that supports the diverse requirements of conversational AI applications while maintaining performance and reliability.
|
||||
botserver's storage architecture distributes data across specialized systems optimized for different access patterns. PostgreSQL handles structured data with transactional integrity. Drive provides scalable object storage for files and documents. Valkey accelerates access to frequently used information. Qdrant enables semantic search through vector storage. Understanding this architecture helps you configure storage appropriately, implement effective backup strategies, and troubleshoot issues when they arise. The result is a storage foundation that supports the diverse requirements of conversational AI applications while maintaining performance and reliability.
|
||||
|
|
@ -1,10 +1,10 @@
|
|||
# Chapter 12: Authentication & Security
|
||||
|
||||
User authentication and permission management for BotServer.
|
||||
User authentication and permission management for botserver.
|
||||
|
||||
## Overview
|
||||
|
||||
BotServer provides enterprise-grade security with flexible authentication options and granular permissions.
|
||||
botserver provides enterprise-grade security with flexible authentication options and granular permissions.
|
||||
|
||||
## Authentication Methods
|
||||
|
||||
|
|
|
|||
|
|
@ -16,7 +16,7 @@ Password security is handled entirely by Zitadel, which provides:
|
|||
### What General Bots Does NOT Do
|
||||
|
||||
- **No password storage**: No password or hash columns in database
|
||||
- **No hashing implementation**: No Argon2/bcrypt code in BotServer
|
||||
- **No hashing implementation**: No Argon2/bcrypt code in botserver
|
||||
- **No password validation**: All validation done by Zitadel
|
||||
- **No password reset logic**: Handled through Zitadel workflows
|
||||
- **No password policies**: Configured in Zitadel admin console
|
||||
|
|
@ -246,7 +246,7 @@ Zitadel's password handling helps meet:
|
|||
- **Professional Implementation**: Security experts maintain Zitadel
|
||||
- **Regular Updates**: Security patches applied by Zitadel team
|
||||
- **Compliance**: Certifications maintained by Zitadel
|
||||
- **No Liability**: Password breaches not BotServer's responsibility
|
||||
- **No Liability**: Password breaches not botserver's responsibility
|
||||
|
||||
### Reduced Attack Surface
|
||||
|
||||
|
|
|
|||
|
|
@ -160,7 +160,7 @@ General Bots integrates with the directory service through:
|
|||
|
||||
1. User registration request sent to directory service
|
||||
2. Directory service creates user account
|
||||
3. User ID returned to BotServer
|
||||
3. User ID returned to botserver
|
||||
4. General Bots creates local user reference
|
||||
5. Session established with General Bots
|
||||
|
||||
|
|
|
|||
|
|
@ -2,7 +2,7 @@
|
|||
|
||||
## 1. Search for Duplicates
|
||||
|
||||
[Search the existing issues](https://github.com/pragmatismo-io/BotServer/issues) before logging a new one.
|
||||
[Search the existing issues](https://github.com/pragmatismo-io/botserver/issues) before logging a new one.
|
||||
|
||||
## 2. Do you have a question?
|
||||
|
||||
|
|
|
|||
|
|
@ -1,10 +1,10 @@
|
|||
# Documentation
|
||||
|
||||
Good documentation is essential for maintaining and growing BotServer. This guide covers documentation standards and practices for contributors.
|
||||
Good documentation is essential for maintaining and growing botserver. This guide covers documentation standards and practices for contributors.
|
||||
|
||||
## Overview
|
||||
|
||||
BotServer documentation includes code documentation through inline comments and doc comments, API documentation, user guides, the BASIC language reference, architecture documentation, and README files throughout the repository.
|
||||
botserver documentation includes code documentation through inline comments and doc comments, API documentation, user guides, the BASIC language reference, architecture documentation, and README files throughout the repository.
|
||||
|
||||
## Documentation Structure
|
||||
|
||||
|
|
@ -216,7 +216,7 @@ Use relative links for internal documentation to ensure links work regardless of
|
|||
|
||||
### Be Clear and Concise
|
||||
|
||||
Write directly and avoid unnecessary words. Instead of "The system employs a sophisticated relational database management system, specifically PostgreSQL, for the purpose of persisting structured information," simply write "BotServer uses PostgreSQL for structured data storage."
|
||||
Write directly and avoid unnecessary words. Instead of "The system employs a sophisticated relational database management system, specifically PostgreSQL, for the purpose of persisting structured information," simply write "botserver uses PostgreSQL for structured data storage."
|
||||
|
||||
### Use Active Voice
|
||||
|
||||
|
|
@ -286,4 +286,4 @@ Documentation-only pull requests are welcome and valuable. They can be merged qu
|
|||
|
||||
## Summary
|
||||
|
||||
Good documentation makes BotServer accessible to users and maintainable for developers. Always consider documentation as part of the development process, not an afterthought. Clear, accurate, and up-to-date documentation is as valuable as the code itself.
|
||||
Good documentation makes botserver accessible to users and maintainable for developers. Always consider documentation as part of the development process, not an afterthought. Clear, accurate, and up-to-date documentation is as valuable as the code itself.
|
||||
|
|
@ -87,13 +87,13 @@ syn match basicComment "^REM.*$"
|
|||
syn match basicComment "'.*$"
|
||||
```
|
||||
|
||||
The plugin provides several commands for interacting with BotServer. Use `:BotDeploy` to deploy the current bot, `:BotRun` to run the current script, `:BotLogs` to view server logs, and `:BotConnect` to connect to the server.
|
||||
The plugin provides several commands for interacting with botserver. Use `:BotDeploy` to deploy the current bot, `:BotRun` to run the current script, `:BotLogs` to view server logs, and `:BotConnect` to connect to the server.
|
||||
|
||||
## Emacs Mode
|
||||
|
||||
### Installation
|
||||
|
||||
Add the BotServer mode to your Emacs configuration:
|
||||
Add the botserver mode to your Emacs configuration:
|
||||
|
||||
```elisp
|
||||
;; ~/.emacs.d/init.el
|
||||
|
|
@ -107,8 +107,8 @@ Add the BotServer mode to your Emacs configuration:
|
|||
The major mode definition provides BASIC script editing support:
|
||||
|
||||
```elisp
|
||||
(define-derived-mode botserver-mode prog-mode "BotServer"
|
||||
"Major mode for editing BotServer BASIC scripts."
|
||||
(define-derived-mode botserver-mode prog-mode "botserver"
|
||||
"Major mode for editing botserver BASIC scripts."
|
||||
(setq-local comment-start "REM ")
|
||||
(setq-local comment-end "")
|
||||
(setq-local indent-line-function 'botserver-indent-line))
|
||||
|
|
@ -120,11 +120,11 @@ The mode includes convenient key bindings: `C-c C-c` runs the current script, `C
|
|||
|
||||
### Installation
|
||||
|
||||
The package can be installed via Package Control by opening the command palette with `Cmd+Shift+P`, selecting "Package Control: Install Package", and searching for "BotServer". For manual installation, clone the repository directly:
|
||||
The package can be installed via Package Control by opening the command palette with `Cmd+Shift+P`, selecting "Package Control: Install Package", and searching for "botserver". For manual installation, clone the repository directly:
|
||||
|
||||
```bash
|
||||
cd ~/Library/Application\ Support/Sublime\ Text/Packages
|
||||
git clone https://github.com/botserver/sublime-botserver BotServer
|
||||
git clone https://github.com/botserver/sublime-botserver botserver
|
||||
```
|
||||
|
||||
The package provides BASIC syntax highlighting, a build system for running scripts, snippets for common patterns, and project templates.
|
||||
|
|
@ -144,7 +144,7 @@ The bundle includes a language grammar for BASIC, commands for deployment, and t
|
|||
|
||||
## Language Server Protocol (LSP)
|
||||
|
||||
BotServer includes an LSP server that works with any LSP-compatible editor. This enables a consistent development experience across different editors and platforms.
|
||||
botserver includes an LSP server that works with any LSP-compatible editor. This enables a consistent development experience across different editors and platforms.
|
||||
|
||||
### Starting the LSP Server
|
||||
|
||||
|
|
|
|||
|
|
@ -1,11 +1,11 @@
|
|||
# Pull Requests
|
||||
|
||||
This guide covers the pull request process for contributing to BotServer, from creation to merge. Understanding this process helps ensure your contributions are reviewed efficiently and merged successfully.
|
||||
This guide covers the pull request process for contributing to botserver, from creation to merge. Understanding this process helps ensure your contributions are reviewed efficiently and merged successfully.
|
||||
|
||||
|
||||
## Overview
|
||||
|
||||
Pull requests are the primary method for contributing code to BotServer. They provide a structured way to propose changes, enabling code review, discussion, and automated testing before changes are merged into the main codebase. Every contribution, whether a bug fix, new feature, or documentation update, follows this process.
|
||||
Pull requests are the primary method for contributing code to botserver. They provide a structured way to propose changes, enabling code review, discussion, and automated testing before changes are merged into the main codebase. Every contribution, whether a bug fix, new feature, or documentation update, follows this process.
|
||||
|
||||
|
||||
## Before Creating a PR
|
||||
|
|
|
|||
|
|
@ -29,7 +29,7 @@ This guide covers setting up a development environment for contributing to Gener
|
|||
### 1. Clone the Repository
|
||||
|
||||
```bash
|
||||
git clone https://github.com/GeneralBots/BotServer.git
|
||||
git clone https://github.com/GeneralBots/botserver.git
|
||||
cd botserver
|
||||
```
|
||||
|
||||
|
|
@ -214,7 +214,7 @@ This configuration:
|
|||
### Remote Monitoring Tips
|
||||
|
||||
```bash
|
||||
# Monitor BotServer logs in real-time
|
||||
# Monitor botserver logs in real-time
|
||||
ssh user@server 'tail -f botserver.log'
|
||||
|
||||
# Watch compilation progress
|
||||
|
|
@ -246,7 +246,7 @@ Check logs in the console output for debugging information.
|
|||
{
|
||||
"type": "lldb",
|
||||
"request": "launch",
|
||||
"name": "Debug BotServer",
|
||||
"name": "Debug botserver",
|
||||
"cargo": {
|
||||
"args": ["build"],
|
||||
"filter": {
|
||||
|
|
@ -392,4 +392,4 @@ See [Contributing Guidelines](./contributing-guidelines.md) for:
|
|||
- Read the [Architecture Overview](../chapter-06/architecture.md)
|
||||
- Explore the [BASIC Language Reference](../chapter-05/README.md)
|
||||
- Review [Code Standards](./standards.md)
|
||||
- Start with a [good first issue](https://github.com/GeneralBots/BotServer/labels/good%20first%20issue)
|
||||
- Start with a [good first issue](https://github.com/GeneralBots/botserver/labels/good%20first%20issue)
|
||||
|
|
@ -1,12 +1,12 @@
|
|||
# Code Standards
|
||||
|
||||
BotServer follows Rust best practices with a unique approach: **all code is fully generated by LLMs** following specific prompts and patterns.
|
||||
botserver follows Rust best practices with a unique approach: **all code is fully generated by LLMs** following specific prompts and patterns.
|
||||
|
||||
## LLM-Generated Code Policy
|
||||
|
||||
### Core Principle
|
||||
|
||||
**All source code in BotServer is generated by Large Language Models (LLMs)**. This ensures consistency, reduces human error, and leverages AI capabilities for optimal code generation.
|
||||
**All source code in botserver is generated by Large Language Models (LLMs)**. This ensures consistency, reduces human error, and leverages AI capabilities for optimal code generation.
|
||||
|
||||
### Important Guidelines
|
||||
|
||||
|
|
@ -178,7 +178,7 @@ fn read_configuration_file(path: &str) -> Result<String, std::io::Error> {
|
|||
use thiserror::Error;
|
||||
|
||||
#[derive(Error, Debug)]
|
||||
pub enum BotServerError {
|
||||
pub enum botserverError {
|
||||
#[error("Database connection failed: {0}")]
|
||||
DatabaseConnection(#[from] diesel::result::Error),
|
||||
|
||||
|
|
@ -245,11 +245,11 @@ let database_url = std::env::var("DATABASE_URL")?;
|
|||
```rust
|
||||
fn validate_and_sanitize_user_input(input: &str) -> Result<String> {
|
||||
if input.len() > MAX_INPUT_LENGTH {
|
||||
return Err(BotServerError::InputTooLong);
|
||||
return Err(botserverError::InputTooLong);
|
||||
}
|
||||
|
||||
if !input.chars().all(char::is_alphanumeric) {
|
||||
return Err(BotServerError::InvalidCharacters);
|
||||
return Err(botserverError::InvalidCharacters);
|
||||
}
|
||||
|
||||
Ok(input.to_string())
|
||||
|
|
@ -302,7 +302,7 @@ Before submitting LLM-generated code:
|
|||
|
||||
## Summary
|
||||
|
||||
BotServer embraces AI-first development where:
|
||||
botserver embraces AI-first development where:
|
||||
1. **All code is LLM-generated** following consistent patterns
|
||||
2. **Comments are forbidden** - code must be self-documenting
|
||||
3. **Documentation lives externally** in dedicated files
|
||||
|
|
|
|||
|
|
@ -1,10 +1,10 @@
|
|||
# Testing
|
||||
|
||||
BotServer follows comprehensive testing practices to ensure reliability, performance, and maintainability of the codebase.
|
||||
botserver follows comprehensive testing practices to ensure reliability, performance, and maintainability of the codebase.
|
||||
|
||||
## Overview
|
||||
|
||||
Testing in BotServer covers:
|
||||
Testing in botserver covers:
|
||||
- Unit tests for individual functions
|
||||
- Integration tests for components
|
||||
- End-to-end tests for workflows
|
||||
|
|
@ -420,4 +420,4 @@ fn test_user_story() {
|
|||
|
||||
## Summary
|
||||
|
||||
Comprehensive testing ensures BotServer's reliability and makes refactoring safe. Focus on writing clear, independent tests that cover both success and failure cases, and maintain good test coverage across the codebase.
|
||||
Comprehensive testing ensures botserver's reliability and makes refactoring safe. Focus on writing clear, independent tests that cover both success and failure cases, and maintain good test coverage across the codebase.
|
||||
|
|
@ -13,26 +13,7 @@ General Bots can run on any device, from mobile phones to minimal embedded hardw
|
|||
- **Education** - Classroom assistants, lab equipment interfaces
|
||||
- **Healthcare** - Patient check-in, medication reminders
|
||||
|
||||
```
|
||||
┌─────────────────────────────────────────────────────────────────────────────┐
|
||||
│ Embedded GB Architecture │
|
||||
├─────────────────────────────────────────────────────────────────────────────┤
|
||||
│ │
|
||||
│ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ │
|
||||
│ │ Display │ │ botserver │ │ llama.cpp │ │
|
||||
│ │ LCD/OLED │────▶│ (Rust) │────▶│ (Local) │ │
|
||||
│ │ TFT/HDMI │ │ Port 8088 │ │ Port 8080 │ │
|
||||
│ └──────────────┘ └──────────────┘ └──────────────┘ │
|
||||
│ │ │ │ │
|
||||
│ │ │ │ │
|
||||
│ ┌──────▼──────┐ ┌──────▼──────┐ ┌──────▼──────┐ │
|
||||
│ │ Keyboard │ │ SQLite │ │ TinyLlama │ │
|
||||
│ │ Buttons │ │ (Data) │ │ GGUF │ │
|
||||
│ │ Touch │ │ │ │ (~700MB) │ │
|
||||
│ └─────────────┘ └─────────────┘ └─────────────┘ │
|
||||
│ │
|
||||
└─────────────────────────────────────────────────────────────────────────────┘
|
||||
```
|
||||
<img src="../assets/chapter-13/embedded-architecture.svg" alt="Embedded GB Architecture" style="max-width: 100%; height: auto;">
|
||||
|
||||
## What's in This Chapter
|
||||
|
||||
|
|
@ -43,6 +24,7 @@ General Bots can run on any device, from mobile phones to minimal embedded hardw
|
|||
- [Supported Hardware](./hardware.md) - SBCs, displays, and peripherals
|
||||
- [Quick Start](./quick-start.md) - Deploy in 5 minutes
|
||||
- [Local LLM](./local-llm.md) - Offline AI with llama.cpp
|
||||
- [Buying Guide](./buying-guide.md) - Choose your first SBC
|
||||
|
||||
### Deployment Options
|
||||
|
||||
|
|
|
|||
|
|
@ -16,24 +16,7 @@ A Single Board Computer (SBC) is a complete computer on a single circuit board.
|
|||
|
||||
### Decision Flowchart
|
||||
|
||||
```
|
||||
┌─────────────────────────┐
|
||||
│ What's your budget? │
|
||||
└───────────┬─────────────┘
|
||||
│
|
||||
┌───────────────────┼───────────────────┐
|
||||
▼ ▼ ▼
|
||||
Under $30 $30-80 $80-150
|
||||
│ │ │
|
||||
▼ ▼ ▼
|
||||
┌───────────────┐ ┌───────────────┐ ┌───────────────┐
|
||||
│ Orange Pi │ │ Raspberry Pi │ │ Orange Pi 5 │
|
||||
│ Zero 3 │ │ 4 / 5 │ │ (with NPU) │
|
||||
│ │ │ │ │ │
|
||||
│ Basic display │ │ Full desktop │ │ Local AI/LLM │
|
||||
│ Simple tasks │ │ Most projects │ │ Edge AI │
|
||||
└───────────────┘ └───────────────┘ └───────────────┘
|
||||
```
|
||||
<img src="../assets/chapter-13/budget-decision-tree.svg" alt="Hardware Budget Decision Tree" style="max-width: 100%; height: auto;">
|
||||
|
||||
### Recommended Starter Kits
|
||||
|
||||
|
|
@ -107,65 +90,61 @@ This board has a 6 TOPS NPU for accelerated AI inference!
|
|||
|
||||
Perfect first project - monitor and log temperature!
|
||||
|
||||
```
|
||||
□ Orange Pi Zero 3 (1GB) $20
|
||||
□ 16GB microSD card $5
|
||||
□ 5V 2A power supply $5
|
||||
□ DHT22 temperature sensor $6
|
||||
□ 0.96" OLED display (I2C) $6
|
||||
□ Jumper wires (female-female) $3
|
||||
─────────────
|
||||
Total: $45
|
||||
```
|
||||
| Item | Price |
|
||||
|------|-------|
|
||||
| Orange Pi Zero 3 (1GB) | $20 |
|
||||
| 16GB microSD card | $5 |
|
||||
| 5V 2A power supply | $5 |
|
||||
| DHT22 temperature sensor | $6 |
|
||||
| 0.96" OLED display (I2C) | $6 |
|
||||
| Jumper wires (female-female) | $3 |
|
||||
| **Total** | **$45** |
|
||||
|
||||
### Smart Doorbell ($70)
|
||||
|
||||
AI-powered doorbell with notifications!
|
||||
|
||||
```
|
||||
□ Raspberry Pi Zero 2 W $15
|
||||
□ Pi Camera Module $25
|
||||
□ Push button $1
|
||||
□ Piezo buzzer $2
|
||||
□ LED (with resistor) $1
|
||||
□ 16GB microSD card $5
|
||||
□ 5V 2.5A power supply $8
|
||||
□ Case $5
|
||||
□ Jumper wires $3
|
||||
─────────────
|
||||
Total: $70
|
||||
```
|
||||
| Item | Price |
|
||||
|------|-------|
|
||||
| Raspberry Pi Zero 2 W | $15 |
|
||||
| Pi Camera Module | $25 |
|
||||
| Push button | $1 |
|
||||
| Piezo buzzer | $2 |
|
||||
| LED (with resistor) | $1 |
|
||||
| 16GB microSD card | $5 |
|
||||
| 5V 2.5A power supply | $8 |
|
||||
| Case | $5 |
|
||||
| Jumper wires | $3 |
|
||||
| **Total** | **$70** |
|
||||
|
||||
### Offline AI Assistant ($150)
|
||||
|
||||
Run AI completely offline - no internet needed!
|
||||
|
||||
```
|
||||
□ Orange Pi 5 (8GB RAM) $89
|
||||
□ 128GB NVMe SSD $20
|
||||
□ 12V 3A power supply $12
|
||||
□ 7" HDMI touchscreen $45
|
||||
□ USB microphone $10
|
||||
□ Case with fan $15
|
||||
□ Jumper wires $3
|
||||
─────────────
|
||||
Total: ~$195
|
||||
```
|
||||
| Item | Price |
|
||||
|------|-------|
|
||||
| Orange Pi 5 (8GB RAM) | $89 |
|
||||
| 128GB NVMe SSD | $20 |
|
||||
| 12V 3A power supply | $12 |
|
||||
| 7" HDMI touchscreen | $45 |
|
||||
| USB microphone | $10 |
|
||||
| Case with fan | $15 |
|
||||
| Jumper wires | $3 |
|
||||
| **Total** | **~$195** |
|
||||
|
||||
### Voice-Controlled Lights ($55)
|
||||
|
||||
Control your lights by talking!
|
||||
|
||||
```
|
||||
□ Raspberry Pi 4 (2GB) $35
|
||||
□ 4-channel relay module $6
|
||||
□ USB microphone $8
|
||||
□ 16GB microSD card $5
|
||||
□ 5V 3A power supply $8
|
||||
□ Jumper wires $3
|
||||
─────────────
|
||||
Total: ~$65
|
||||
```
|
||||
| Item | Price |
|
||||
|------|-------|
|
||||
| Raspberry Pi 4 (2GB) | $35 |
|
||||
| 4-channel relay module | $6 |
|
||||
| USB microphone | $8 |
|
||||
| 16GB microSD card | $5 |
|
||||
| 5V 3A power supply | $8 |
|
||||
| Jumper wires | $3 |
|
||||
| **Total** | **~$65** |
|
||||
|
||||
## Where to Buy (By Region)
|
||||
|
||||
|
|
|
|||
|
|
@ -39,22 +39,7 @@
|
|||
|
||||
The Orange Pi 5 with RK3588S is ideal for embedded LLM:
|
||||
|
||||
```
|
||||
┌─────────────────────────────────────────────────────────────┐
|
||||
│ Orange Pi 5 - Best for Offline AI │
|
||||
├─────────────────────────────────────────────────────────────┤
|
||||
│ CPU: Rockchip RK3588S (4x A76 + 4x A55) │
|
||||
│ NPU: 6 TOPS (Neural Processing Unit) │
|
||||
│ GPU: Mali-G610 MP4 │
|
||||
│ RAM: 4GB / 8GB / 16GB LPDDR4X │
|
||||
│ Storage: M.2 NVMe + eMMC + microSD │
|
||||
│ │
|
||||
│ LLM Performance: │
|
||||
│ ├─ TinyLlama 1.1B Q4: ~8-12 tokens/sec │
|
||||
│ ├─ Phi-2 2.7B Q4: ~4-6 tokens/sec │
|
||||
│ └─ With NPU (rkllm): ~20-30 tokens/sec │
|
||||
└─────────────────────────────────────────────────────────────┘
|
||||
```
|
||||
<img src="../assets/chapter-13/orange-pi-5-specs.svg" alt="Orange Pi 5 Specifications" style="max-width: 100%; height: auto;">
|
||||
|
||||
## Displays
|
||||
|
||||
|
|
@ -68,13 +53,7 @@ For text-only interfaces:
|
|||
| HD44780 20x4 | 20 chars × 4 lines | I2C/GPIO | More context |
|
||||
| LCD2004 | 20 chars × 4 lines | I2C | Industrial |
|
||||
|
||||
**Example output on 16x2:**
|
||||
```
|
||||
┌────────────────┐
|
||||
│> How can I help│
|
||||
│< Processing... │
|
||||
└────────────────┘
|
||||
```
|
||||
**Example output on 16x2:** Simple text display showing user prompt and bot status.
|
||||
|
||||
### OLED Displays
|
||||
|
||||
|
|
@ -138,17 +117,7 @@ For low-power, readable in sunlight:
|
|||
|
||||
### Buttons & GPIO
|
||||
|
||||
```
|
||||
┌─────────────────────────────────────────────┐
|
||||
│ Simple 4-Button Interface │
|
||||
├─────────────────────────────────────────────┤
|
||||
│ │
|
||||
│ [◄ PREV] [▲ UP] [▼ DOWN] [► SELECT] │
|
||||
│ │
|
||||
│ GPIO 17 GPIO 27 GPIO 22 GPIO 23 │
|
||||
│ │
|
||||
└─────────────────────────────────────────────┘
|
||||
```
|
||||
<img src="../assets/chapter-13/gpio-button-interface.svg" alt="GPIO Button Interface" style="max-width: 100%; height: auto;">
|
||||
|
||||
## Enclosures
|
||||
|
||||
|
|
|
|||
Some files were not shown because too many files have changed in this diff Show more
Loading…
Add table
Reference in a new issue