Lowercase botserver/botbook references, add bottemplates repo, update autonomous tasks docs
This commit is contained in:
parent
33fb240783
commit
83db827c3f
109 changed files with 2173 additions and 1389 deletions
|
|
@ -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
|
||||
|
|
|
|||
29
README.md
29
README.md
|
|
@ -1,6 +1,6 @@
|
|||
# General Bots
|
||||
|
||||
|
||||
|
||||
|
||||
**Enterprise-Grade LLM Orchestrator & AI Automation Platform**
|
||||
|
||||
|
|
@ -18,11 +18,12 @@ A strongly-typed, self-hosted conversational platform focused on convention over
|
|||
|
||||
| Repository | Description | Status |
|
||||
|------------|-------------|--------|
|
||||
| [**botserver**](https://github.com/GeneralBots/BotServer) | Core API server - LLM orchestration, automation, integrations | ✅ Production |
|
||||
| [**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 |
|
||||
| [**botbook**](https://github.com/GeneralBots/BotBook) | Documentation - mdBook format, multi-language | ✅ 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 |
|
||||
|
||||
---
|
||||
|
||||
|
|
@ -37,12 +38,12 @@ A strongly-typed, self-hosted conversational platform focused on convention over
|
|||
|
||||
```bash
|
||||
# Clone and run
|
||||
git clone https://github.com/GeneralBots/BotServer
|
||||
cd BotServer
|
||||
git clone https://github.com/GeneralBots/botserver
|
||||
cd botserver
|
||||
cargo run
|
||||
```
|
||||
|
||||
On first run, BotServer automatically:
|
||||
On first run, botserver automatically:
|
||||
- Installs required components (PostgreSQL, S3 storage, Cache, LLM)
|
||||
- Sets up database with migrations
|
||||
- Downloads AI models
|
||||
|
|
@ -125,7 +126,7 @@ Tauri wrapper adding native capabilities:
|
|||
|
||||
### botlib (Shared Library)
|
||||
Common Rust code shared across projects:
|
||||
- HTTP client for BotServer communication
|
||||
- HTTP client for botserver communication
|
||||
- Shared types and models
|
||||
- Branding and configuration utilities
|
||||
- Error handling
|
||||
|
|
@ -136,11 +137,11 @@ Common Rust code shared across projects:
|
|||
|
||||
```bash
|
||||
# Clone all repositories
|
||||
git clone https://github.com/GeneralBots/BotServer botserver
|
||||
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
|
||||
git clone https://github.com/GeneralBots/botbook botbook
|
||||
|
||||
# Build all (from each directory)
|
||||
cd botlib && cargo build
|
||||
|
|
@ -153,10 +154,10 @@ 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
|
||||
- **[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
|
||||
|
||||
---
|
||||
|
||||
|
|
@ -184,7 +185,7 @@ 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).
|
||||
We welcome contributions! See our [Contributing Guidelines](https://github.com/GeneralBots/botserver/blob/main/docs/src/chapter-13-community/README.md).
|
||||
|
||||
### Contributors
|
||||
|
||||
|
|
|
|||
|
|
@ -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 |
|
||||
| Auto 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 |
|
||||
| ⚡ **Auto Tasks** | LLM-powered intelligent task execution |
|
||||
| ✉ **Mail** | Send and receive emails |
|
||||
| 📅 **Calendar** | Schedule meetings and events |
|
||||
| 🎥 **Meet** | Video calls with your team |
|
||||
|
|
@ -38,7 +38,7 @@ Click any app icon in the top-right menu (⋮⋮⋮) to open it.
|
|||
|-------|-------|
|
||||
| `Alt + 1` | Chat |
|
||||
| `Alt + 2` | Drive |
|
||||
| `Alt + 3` | Tasks |
|
||||
| `Alt + 3` | Auto Tasks |
|
||||
| `Alt + 4` | Mail |
|
||||
| `Alt + 5` | Calendar |
|
||||
| `Alt + 6` | Meet |
|
||||
|
|
@ -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
|
||||
- [Auto 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
|
||||
|
|
|
|||
|
|
@ -22,7 +22,7 @@ The Suite includes integrated applications:
|
|||
|-----|---------|
|
||||
| 💬 Chat | AI assistant conversations |
|
||||
| 📁 Drive | File management |
|
||||
| ✓ Tasks | To-do lists |
|
||||
| ⚡ Auto Tasks | LLM-powered intelligent execution |
|
||||
| ✉ Mail | Email client |
|
||||
| 📅 Calendar | Scheduling |
|
||||
| 🎥 Meet | Video calls |
|
||||
|
|
|
|||
|
|
@ -1,126 +1,331 @@
|
|||
# Tasks
|
||||
# Auto Tasks
|
||||
|
||||
> **Your personal to-do list**
|
||||
> **LLM-Powered Intelligent Task Execution**
|
||||
|
||||
---
|
||||
|
||||
## What is Tasks?
|
||||
<img src="../../assets/chapter-04/autotask-interface.svg" alt="Auto Tasks Interface" style="max-width: 100%; height: auto;">
|
||||
|
||||
Tasks helps you keep track of what you need to do. Add tasks, check them off when done, and stay organized.
|
||||
## What is Auto Tasks?
|
||||
|
||||
Auto Tasks is a revolutionary approach to task automation. Instead of manually creating 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 old way:** Create a task → Do it yourself → Mark complete
|
||||
|
||||
**The Auto Tasks way:** Describe your goal → LLM plans it → System executes it → 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 Intent** | Write what you want in plain English |
|
||||
| **2. Compile & Plan** | LLM analyzes intent, generates execution plan |
|
||||
| **3. Review Plan** | 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 an Auto Task
|
||||
|
||||
Click the **checkbox** next to any task to mark it done.
|
||||
### 1. 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
|
||||
|
||||
### 2. 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 |
|
||||
|
||||
### 3. 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 |
|
||||
|
||||
### 4. 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'll see a detailed plan:
|
||||
|
||||
Starred tasks appear in the **Priority** tab for quick access.
|
||||
### Plan Header
|
||||
|
||||
- **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:
|
||||
- **Step Number & Priority** - Order and importance
|
||||
- **Step Name** - What this step does
|
||||
- **Keywords** - BASIC keywords that will be used
|
||||
- **Risk Level** - Risk for this specific step
|
||||
|
||||
### Resource Estimates
|
||||
|
||||
- **Compute** - Processing hours needed
|
||||
- **Storage** - Disk space required
|
||||
- **API Calls** - External API requests
|
||||
- **LLM Tokens** - Token consumption estimate
|
||||
|
||||
### 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 Active 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
|
||||
|
||||
- **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'll see:
|
||||
- **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:**
|
||||
- ✅ **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!
|
||||
| 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 |
|
||||
|
||||
---
|
||||
|
||||
## Keyboard Shortcuts
|
||||
## Execution Log
|
||||
|
||||
| Press | What Happens |
|
||||
|-------|--------------|
|
||||
| `Enter` | Add task (when typing) |
|
||||
| `Escape` | Cancel editing |
|
||||
Expand any task to see its execution log:
|
||||
- Timestamp for each action
|
||||
- Step transitions
|
||||
- Approval/decision records
|
||||
- Error messages if any
|
||||
- Output from each step
|
||||
|
||||
---
|
||||
|
||||
## Creating Tasks from Chat
|
||||
|
||||
You can also create tasks by talking to your bot:
|
||||
You can also create Auto 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 an Auto Task for that. Here's the plan:
|
||||
- 5 steps, estimated 3 hours
|
||||
- Includes: database setup, authentication, dashboard, API integration
|
||||
- Risk: Low
|
||||
-
|
||||
Should I execute this plan?"
|
||||
|
||||
**You:** "What tasks do I have today?"
|
||||
**You:** "Yes, go ahead"
|
||||
|
||||
**Bot:** "You have 3 tasks for today..."
|
||||
**Bot:** "🚀 Auto 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 Auto 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:**
|
||||
- "Create a sales dashboard for Q4 data with charts showing revenue by region"
|
||||
- "Build an email drip campaign: welcome email, 3-day follow-up, 7-day offer"
|
||||
- "Analyze customer feedback CSV and generate sentiment report"
|
||||
|
||||
❌ **Don't:**
|
||||
- "Make something" (too vague)
|
||||
- "Do the thing we discussed" (no context)
|
||||
- "Fix it" (what needs fixing?)
|
||||
|
||||
### Choosing Execution Mode
|
||||
|
||||
- **New to Auto Tasks?** Start with Supervised mode
|
||||
- **Routine tasks?** Use Semi-Automatic
|
||||
- **Trusted, tested workflows?** Fully Automatic is fine
|
||||
- **Experimenting?** Always use Dry Run first
|
||||
|
||||
### 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
|
||||
|
||||
### High Risk Warning
|
||||
|
||||
- Consider using Supervised mode
|
||||
- Review each step carefully
|
||||
- Use Simulate before Execute
|
||||
|
||||
---
|
||||
|
||||
## Settings
|
||||
|
||||
Configure Auto Tasks behavior in Settings:
|
||||
|
||||
- **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) - How the machine does the work
|
||||
- [CREATE SITE Keyword](../../06-gbdialog/keyword-create-site.md) - App generation details
|
||||
- [Calendar](./calendar.md) - Scheduled Auto Tasks appear here
|
||||
- [Chat](./chat.md) - Create tasks through conversation
|
||||
- [Analytics](./analytics.md) - Task execution metrics
|
||||
|
|
@ -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.
|
||||
|
|
@ -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 |
|
||||
| ⚡ | **Auto 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: Auto Tasks - LLM-Powered Execution
|
||||
|
||||
### What Tasks Does
|
||||
### What Auto Tasks Does
|
||||
|
||||
Tasks helps you track what needs to be done. Create to-do lists, set due dates, and mark items complete.
|
||||
Auto 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
|
||||
### The Auto 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="Auto Tasks Interface" style="max-width: 100%; height: auto;">
|
||||
|
||||
### Adding a Task
|
||||
### Creating an Auto 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
|
||||
|
||||
### Creating Tasks from Chat
|
||||
- **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 Auto 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 Auto Task for that. Here's the plan:
|
||||
- 5 steps, estimated 3 hours
|
||||
- Risk: Low
|
||||
Should I execute this plan?
|
||||
You: Yes, go ahead
|
||||
Bot: 🚀 Auto 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
|
||||
|
|
@ -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.
|
||||
|
|
@ -26,9 +26,6 @@ General Bots can run on any device, from mobile phones to minimal embedded hardw
|
|||
- [Local LLM](./local-llm.md) - Offline AI with llama.cpp
|
||||
- [Buying Guide](./buying-guide.md) - Choose your first SBC
|
||||
|
||||
### Robotics
|
||||
- [Humanoid Robots](./humanoid.md) - Build intelligent humanoids with CV, LLM, and movement control
|
||||
|
||||
### Deployment Options
|
||||
|
||||
| Platform | Use Case | Requirements |
|
||||
|
|
@ -37,4 +34,3 @@ General Bots can run on any device, from mobile phones to minimal embedded hardw
|
|||
| **Raspberry Pi** | IoT, displays, terminals | 1GB+ RAM |
|
||||
| **Orange Pi** | Full offline AI | 4GB+ RAM for LLM |
|
||||
| **Industrial** | Factory, retail, healthcare | Any ARM/x86 SBC |
|
||||
| **Humanoid Robots** | Service, reception, research | Servo kit + compute board |
|
||||
|
|
|
|||
|
|
@ -1,754 +0,0 @@
|
|||
# Humanoid Robotics with General Bots
|
||||
|
||||
Build custom humanoid robots powered by General Bots, using computer vision from botmodels, LLM intelligence from botserver, and BASIC keywords for movement control.
|
||||
|
||||
## Why Run General Bots on a Humanoid?
|
||||
|
||||
A humanoid robot without an LLM orchestrator is just an expensive puppet. The hardware handles joints and sensors, but something needs to decide *what* to do with them. That's where General Bots comes in.
|
||||
|
||||
**The robot becomes a server.** The same botserver that handles WhatsApp messages and web chat now handles servo commands and camera feeds. Your humanoid runs:
|
||||
|
||||
- **botserver** on port 8088 — conversation, decisions, tool execution
|
||||
- **llama.cpp** on port 8080 — local LLM inference (optional, for offline)
|
||||
- **botmodels** — computer vision pipeline for face/object detection
|
||||
- **Stalwart** — yes, your robot can have its own email server
|
||||
- **PostgreSQL** — conversation history, user recognition data
|
||||
|
||||
This isn't theoretical. The same stack that powers enterprise chatbots runs on a Jetson Orin Nano inside a robot chassis. When someone walks up and says "where's the bathroom?", the request flows through the same LLM pipeline, triggers the same BASIC keywords, and the response happens to include servo movements instead of just text.
|
||||
|
||||
**Practical benefits:**
|
||||
|
||||
| Traditional Robot | GB-Powered Robot |
|
||||
|-------------------|------------------|
|
||||
| Hardcoded responses | LLM-generated natural conversation |
|
||||
| Fixed behavior scripts | Event-driven, adaptive responses |
|
||||
| Separate control systems | Unified orchestration |
|
||||
| Cloud-dependent | Fully offline capable |
|
||||
| Custom integration work | Standard GB packages (.gbai) |
|
||||
|
||||
The robot is just another deployment target. Same .gbai packages, same BASIC scripts, same tools — but with `ROBOT WALK` and `SERVO MOVE` alongside `SEND MAIL` and `POST`.
|
||||
|
||||
## Overview
|
||||
|
||||
General Bots transforms humanoid robot kits into intelligent conversational assistants capable of:
|
||||
|
||||
- **Natural conversation** via LLM integration
|
||||
- **Visual recognition** using botmodels CV pipelines
|
||||
- **Expressive movement** through BASIC keyword commands
|
||||
- **Autonomous behavior** with event-driven triggers
|
||||
|
||||
<img src="../assets/chapter-13/humanoid-architecture.svg" alt="Humanoid Robot Architecture" style="max-width: 100%; height: auto;">
|
||||
|
||||
## Supported Robot Kits
|
||||
|
||||
### Consumer Kits
|
||||
|
||||
| Kit | DOF | Height | Price | Best For |
|
||||
|-----|-----|--------|-------|----------|
|
||||
| **Unitree G1** | 23 | 127cm | $16,000 | Research, commercial |
|
||||
| **Unitree H1** | 19 | 180cm | $90,000 | Industrial, research |
|
||||
| **UBTECH Walker S** | 41 | 145cm | Contact | Enterprise service |
|
||||
| **Fourier GR-1** | 40 | 165cm | $100,000+ | Research |
|
||||
| **Agility Digit** | 16 | 175cm | Lease | Warehouse, logistics |
|
||||
|
||||
### DIY/Maker Kits
|
||||
|
||||
| Kit | DOF | Height | Price | Best For |
|
||||
|-----|-----|--------|-------|----------|
|
||||
| **Poppy Humanoid** | 25 | 83cm | $8,000 | Education, research |
|
||||
| **InMoov** | 22+ | 170cm | $1,500+ | Makers, open source |
|
||||
| **Reachy** | 14 | Torso | $15,000 | HRI research |
|
||||
| **NimbRo-OP2X** | 20 | 95cm | $30,000 | RoboCup, research |
|
||||
| **ROBOTIS OP3** | 20 | 51cm | $11,000 | Education, competition |
|
||||
|
||||
### Affordable Entry Points
|
||||
|
||||
| Kit | DOF | Height | Price | Best For |
|
||||
|-----|-----|--------|-------|----------|
|
||||
| **ROBOTIS MINI** | 16 | 27cm | $500 | Learning, hobby |
|
||||
| **Lynxmotion SES-V2** | 17 | 40cm | $800 | Education |
|
||||
| **Hiwonder TonyPi** | 16 | 35cm | $400 | Raspberry Pi projects |
|
||||
| **XGO-Mini** | 12 | 20cm | $350 | Quadruped + arm |
|
||||
|
||||
## Architecture
|
||||
|
||||
### System Components
|
||||
|
||||
The robot runs the full General Bots stack:
|
||||
|
||||
| Component | Role | Technology |
|
||||
|-----------|------|------------|
|
||||
| **botserver** | Brain - LLM, conversation, decisions | Rust, Port 8088 |
|
||||
| **botmodels** | Eyes - CV, face recognition, object detection | Python, ONNX |
|
||||
| **BASIC Runtime** | Motor control - movement sequences | Keywords → servo commands |
|
||||
| **Hardware Bridge** | Translation layer | GPIO, Serial, CAN bus |
|
||||
| **llama.cpp** | Local LLM (optional) | C++, Port 8080 |
|
||||
| **PostgreSQL** | User data, conversation history | SQLite for embedded |
|
||||
| **SeaweedFS** | File storage (documents, images) | Optional |
|
||||
| **Stalwart** | Email server — robot has its own inbox | Optional |
|
||||
|
||||
Yes, your robot can receive emails. A visitor sends an email to `robot@company.com`, and the humanoid can respond, schedule meetings, or notify staff. Same stack, different form factor.
|
||||
|
||||
### Communication Flow
|
||||
|
||||
| Step | From | To | Protocol |
|
||||
|------|------|----|----------|
|
||||
| 1 | Microphone | botserver | Audio stream / STT |
|
||||
| 2 | botserver | LLM | HTTP API |
|
||||
| 3 | LLM response | BASIC interpreter | Internal |
|
||||
| 4 | BASIC keywords | Hardware bridge | Serial/GPIO |
|
||||
| 5 | Hardware bridge | Servos | PWM/CAN |
|
||||
| 6 | Camera | botmodels | Video stream |
|
||||
| 7 | botmodels | botserver | Detection events |
|
||||
|
||||
## Hardware Setup
|
||||
|
||||
### Computing Options
|
||||
|
||||
| Option | Specs | Use Case |
|
||||
|--------|-------|----------|
|
||||
| **Jetson Orin Nano** | 8GB, 40 TOPS | Full CV + local LLM |
|
||||
| **Raspberry Pi 5** | 8GB, no NPU | Cloud LLM, basic CV |
|
||||
| **Orange Pi 5** | 8GB, 6 TOPS NPU | Local LLM, basic CV |
|
||||
| **Intel NUC** | 32GB, x86 | Maximum performance |
|
||||
|
||||
### Servo Controllers
|
||||
|
||||
| Controller | Channels | Interface | Best For |
|
||||
|------------|----------|-----------|----------|
|
||||
| **PCA9685** | 16 PWM | I2C | Small robots |
|
||||
| **Pololu Maestro** | 6-24 | USB/Serial | Hobby servos |
|
||||
| **Dynamixel U2D2** | 254 | USB/TTL/RS485 | Dynamixel servos |
|
||||
| **ODrive** | 2 BLDC | USB/CAN | High-torque joints |
|
||||
|
||||
### Sensor Integration
|
||||
|
||||
| Sensor | Purpose | Interface |
|
||||
|--------|---------|-----------|
|
||||
| USB Camera | Vision, face detection | USB/CSI |
|
||||
| IMU (MPU6050) | Balance, orientation | I2C |
|
||||
| ToF (VL53L0X) | Distance sensing | I2C |
|
||||
| Microphone Array | Voice input, direction | USB/I2S |
|
||||
| Force Sensors | Grip feedback | ADC |
|
||||
|
||||
## Event-Driven Robotics with ON Events
|
||||
|
||||
General Bots uses an **event-driven architecture** - no loops needed. The robot reacts to events automatically.
|
||||
|
||||
### Vision Events
|
||||
|
||||
```basic
|
||||
' React when a person is detected
|
||||
ON CV "person" DETECTED CALL person_detected
|
||||
|
||||
' React when a specific person is recognized
|
||||
ON CV "face" RECOGNIZED CALL greet_person
|
||||
|
||||
' React when an object is seen
|
||||
ON CV "cat" DETECTED CALL react_to_cat
|
||||
|
||||
' React when someone waves
|
||||
ON CV "gesture:wave" DETECTED CALL wave_back
|
||||
|
||||
' React when someone approaches
|
||||
ON CV "person" DISTANCE < 1.5 CALL person_approaching
|
||||
```
|
||||
|
||||
### Voice Events
|
||||
|
||||
```basic
|
||||
' React to wake word
|
||||
ON HEAR "Hey robot" CALL wake_up
|
||||
|
||||
' React to any speech
|
||||
ON HEAR CALL process_speech
|
||||
|
||||
' React to specific commands
|
||||
ON HEAR "follow me" CALL start_following
|
||||
ON HEAR "stop" CALL emergency_stop
|
||||
ON HEAR "sit down" CALL sit_pose
|
||||
```
|
||||
|
||||
### Sensor Events
|
||||
|
||||
```basic
|
||||
' React to balance issues
|
||||
ON IMU TILT > 15 CALL stabilize
|
||||
|
||||
' React to touch
|
||||
ON TOUCH "head" CALL head_touched
|
||||
ON TOUCH "hand_left" CALL hand_touched
|
||||
|
||||
' React to obstacles
|
||||
ON DISTANCE "front" < 0.5 CALL obstacle_detected
|
||||
|
||||
' React to battery level
|
||||
ON BATTERY < 20 CALL low_battery_warning
|
||||
```
|
||||
|
||||
### Time Events
|
||||
|
||||
```basic
|
||||
' Scheduled behaviors
|
||||
ON SCHEDULE "0 9 * * *" CALL morning_greeting
|
||||
ON SCHEDULE "*/5 * * * *" CALL idle_animation
|
||||
|
||||
' Periodic checks
|
||||
ON INTERVAL 30000 CALL check_surroundings
|
||||
```
|
||||
|
||||
## Movement Tools
|
||||
|
||||
Define robot capabilities as **TOOLS** that the LLM can call naturally during conversation.
|
||||
|
||||
### Basic Movement Tools
|
||||
|
||||
```basic
|
||||
' wave-hello.bas
|
||||
PARAM person_name DESCRIPTION "Name of person to wave at"
|
||||
|
||||
TALK "Hello " + person_name + "!"
|
||||
ROBOT ARM "right", action: "wave"
|
||||
WAIT 1500
|
||||
ROBOT POSE "stand"
|
||||
```
|
||||
|
||||
```basic
|
||||
' point-direction.bas
|
||||
PARAM direction DESCRIPTION "Direction to point: left, right, forward, behind"
|
||||
|
||||
SELECT CASE direction
|
||||
CASE "left"
|
||||
ROBOT ARM "left", action: "point"
|
||||
TALK "It's over there to the left"
|
||||
CASE "right"
|
||||
ROBOT ARM "right", action: "point"
|
||||
TALK "It's over there to the right"
|
||||
CASE "forward"
|
||||
ROBOT ARM "right", action: "extend"
|
||||
TALK "It's straight ahead"
|
||||
CASE "behind"
|
||||
ROBOT TURN 180
|
||||
ROBOT ARM "right", action: "point"
|
||||
TALK "It's behind us"
|
||||
END SELECT
|
||||
```
|
||||
|
||||
```basic
|
||||
' bow-greeting.bas
|
||||
PARAM style DESCRIPTION "Bow style: formal, casual, deep"
|
||||
|
||||
SELECT CASE style
|
||||
CASE "formal"
|
||||
ROBOT HEAD "look", pan: 0, tilt: -30
|
||||
WAIT 1000
|
||||
CASE "casual"
|
||||
ROBOT HEAD "nod"
|
||||
CASE "deep"
|
||||
ROBOT POSE "bow"
|
||||
WAIT 1500
|
||||
ROBOT POSE "stand"
|
||||
END SELECT
|
||||
```
|
||||
|
||||
### Navigation Tools
|
||||
|
||||
```basic
|
||||
' walk-to-location.bas
|
||||
PARAM location DESCRIPTION "Where to walk: reception, elevator, exit, charging_station"
|
||||
|
||||
locations = {
|
||||
"reception": [0, 0],
|
||||
"elevator": [5, 2],
|
||||
"exit": [10, 0],
|
||||
"charging_station": [-2, 1]
|
||||
}
|
||||
|
||||
target = locations[location]
|
||||
ROBOT NAVIGATE target[0], target[1]
|
||||
TALK "I'll take you to the " + location
|
||||
```
|
||||
|
||||
```basic
|
||||
' follow-person.bas
|
||||
PARAM duration_seconds DESCRIPTION "How long to follow in seconds"
|
||||
|
||||
ROBOT MODE "follow"
|
||||
TALK "I'll follow you for " + duration_seconds + " seconds"
|
||||
WAIT duration_seconds * 1000
|
||||
ROBOT MODE "stationary"
|
||||
TALK "Okay, I'll stay here now"
|
||||
```
|
||||
|
||||
### Expressive Tools
|
||||
|
||||
```basic
|
||||
' show-emotion.bas
|
||||
PARAM emotion DESCRIPTION "Emotion to display: happy, sad, surprised, thinking, confused"
|
||||
|
||||
SELECT CASE emotion
|
||||
CASE "happy"
|
||||
ROBOT DISPLAY "face_happy"
|
||||
ROBOT HEAD "nod"
|
||||
CASE "sad"
|
||||
ROBOT DISPLAY "face_sad"
|
||||
ROBOT HEAD "look", pan: 0, tilt: -20
|
||||
CASE "surprised"
|
||||
ROBOT DISPLAY "face_surprised"
|
||||
ROBOT HEAD "look", pan: 0, tilt: 10
|
||||
CASE "thinking"
|
||||
ROBOT DISPLAY "face_thinking"
|
||||
ROBOT HEAD "look", pan: 20, tilt: 10
|
||||
CASE "confused"
|
||||
ROBOT DISPLAY "face_confused"
|
||||
ROBOT HEAD "tilt", angle: 15
|
||||
END SELECT
|
||||
```
|
||||
|
||||
```basic
|
||||
' dance-move.bas
|
||||
PARAM style DESCRIPTION "Dance style: wave, robot, celebration"
|
||||
|
||||
SELECT CASE style
|
||||
CASE "wave"
|
||||
SEQUENCE PLAY "dance_wave"
|
||||
CASE "robot"
|
||||
SEQUENCE PLAY "dance_robot"
|
||||
CASE "celebration"
|
||||
SEQUENCE PLAY "dance_celebration"
|
||||
TALK "Woohoo!"
|
||||
END SELECT
|
||||
```
|
||||
|
||||
## Event Handlers
|
||||
|
||||
### Person Detection Handler
|
||||
|
||||
```basic
|
||||
' on-person-detected.bas
|
||||
' Called automatically when ON CV "person" DETECTED fires
|
||||
|
||||
person = EVENT.data
|
||||
|
||||
' Turn to face the person
|
||||
ROBOT HEAD "look", pan: person.direction.x, tilt: person.direction.y
|
||||
|
||||
' Check if we know them
|
||||
IF person.identity <> "unknown" THEN
|
||||
USE TOOL "wave-hello", person_name: person.identity
|
||||
ELSE
|
||||
TALK "Hello! Welcome. How can I help you?"
|
||||
USE TOOL "bow-greeting", style: "casual"
|
||||
END IF
|
||||
```
|
||||
|
||||
### Cat Detection Handler
|
||||
|
||||
```basic
|
||||
' on-cat-detected.bas
|
||||
' Called automatically when ON CV "cat" DETECTED fires
|
||||
|
||||
cat = EVENT.data
|
||||
|
||||
TALK "Oh, I see a cat!"
|
||||
ROBOT HEAD "look", pan: cat.direction.x, tilt: cat.direction.y
|
||||
USE TOOL "show-emotion", emotion: "happy"
|
||||
|
||||
' Crouch down to cat level
|
||||
ROBOT POSE "crouch"
|
||||
TALK "Here kitty kitty!"
|
||||
WAIT 3000
|
||||
ROBOT POSE "stand"
|
||||
```
|
||||
|
||||
### Gesture Handler
|
||||
|
||||
```basic
|
||||
' on-wave-detected.bas
|
||||
' Called automatically when ON CV "gesture:wave" DETECTED fires
|
||||
|
||||
gesture = EVENT.data
|
||||
|
||||
' Wave back
|
||||
ROBOT HEAD "look", pan: gesture.direction.x, tilt: gesture.direction.y
|
||||
USE TOOL "wave-hello", person_name: "there"
|
||||
```
|
||||
|
||||
### Speech Handler
|
||||
|
||||
```basic
|
||||
' on-speech.bas
|
||||
' Called automatically when ON HEAR fires
|
||||
|
||||
speech = EVENT.data.text
|
||||
|
||||
' Let LLM decide what to do with available tools
|
||||
response = LLM speech
|
||||
|
||||
' LLM automatically calls tools like:
|
||||
' - wave-hello when greeting someone
|
||||
' - point-direction when giving directions
|
||||
' - show-emotion to express feelings
|
||||
' - walk-to-location when guiding someone
|
||||
|
||||
TALK response
|
||||
```
|
||||
|
||||
### Balance Handler
|
||||
|
||||
```basic
|
||||
' on-balance-issue.bas
|
||||
' Called automatically when ON IMU TILT > 15 fires
|
||||
|
||||
ROBOT BALANCE ON
|
||||
TALK "Whoa, let me steady myself"
|
||||
|
||||
stable = ROBOT STABLE
|
||||
IF NOT stable THEN
|
||||
ROBOT POSE "wide_stance"
|
||||
WAIT 1000
|
||||
END IF
|
||||
|
||||
ROBOT BALANCE OFF
|
||||
```
|
||||
|
||||
### Low Battery Handler
|
||||
|
||||
```basic
|
||||
' on-low-battery.bas
|
||||
' Called automatically when ON BATTERY < 20 fires
|
||||
|
||||
TALK "My battery is getting low. I need to charge soon."
|
||||
USE TOOL "show-emotion", emotion: "sad"
|
||||
|
||||
IF BATTERY < 10 THEN
|
||||
TALK "I really need to go charge now. Excuse me."
|
||||
USE TOOL "walk-to-location", location: "charging_station"
|
||||
END IF
|
||||
```
|
||||
|
||||
## Configuration
|
||||
|
||||
### Robot Definition File
|
||||
|
||||
Create `robot.csv` in your `.gbot` folder:
|
||||
|
||||
| name | value |
|
||||
|------|-------|
|
||||
| robot_type | humanoid |
|
||||
| controller | PCA9685 |
|
||||
| controller_address | 0x40 |
|
||||
| servo_count | 16 |
|
||||
| balance_enabled | true |
|
||||
| cv_enabled | true |
|
||||
| cv_model | yolov8n |
|
||||
| face_model | arcface |
|
||||
|
||||
### Servo Mapping
|
||||
|
||||
Create `servos.csv` to map joints to channels:
|
||||
|
||||
| joint | channel | min_angle | max_angle | home | inverted |
|
||||
|-------|---------|-----------|-----------|------|----------|
|
||||
| head_pan | 0 | -90 | 90 | 0 | false |
|
||||
| head_tilt | 1 | -45 | 45 | 0 | false |
|
||||
| left_shoulder | 2 | -90 | 180 | 0 | false |
|
||||
| left_elbow | 3 | 0 | 135 | 90 | false |
|
||||
| left_wrist | 4 | -90 | 90 | 0 | false |
|
||||
| right_shoulder | 5 | -90 | 180 | 0 | true |
|
||||
| right_elbow | 6 | 0 | 135 | 90 | true |
|
||||
| right_wrist | 7 | -90 | 90 | 0 | true |
|
||||
| left_hip | 8 | -45 | 45 | 0 | false |
|
||||
| left_knee | 9 | 0 | 90 | 0 | false |
|
||||
| left_ankle | 10 | -30 | 30 | 0 | false |
|
||||
| right_hip | 11 | -45 | 45 | 0 | true |
|
||||
| right_knee | 12 | 0 | 90 | 0 | true |
|
||||
| right_ankle | 13 | -30 | 30 | 0 | true |
|
||||
| left_grip | 14 | 0 | 90 | 0 | false |
|
||||
| right_grip | 15 | 0 | 90 | 0 | false |
|
||||
|
||||
### Event Registration
|
||||
|
||||
Create `events.csv` to register event handlers:
|
||||
|
||||
| event | handler | enabled |
|
||||
|-------|---------|---------|
|
||||
| CV:person:detected | on-person-detected.bas | true |
|
||||
| CV:cat:detected | on-cat-detected.bas | true |
|
||||
| CV:gesture:wave:detected | on-wave-detected.bas | true |
|
||||
| HEAR | on-speech.bas | true |
|
||||
| IMU:tilt:15 | on-balance-issue.bas | true |
|
||||
| BATTERY:20 | on-low-battery.bas | true |
|
||||
|
||||
### Motion Sequences
|
||||
|
||||
Create `motions.csv` for predefined sequences:
|
||||
|
||||
| name | frames |
|
||||
|------|--------|
|
||||
| wave | [{"t":0,"joints":{"right_shoulder":90}},{"t":500,"joints":{"right_shoulder":120}},{"t":1000,"joints":{"right_shoulder":90}}] |
|
||||
| bow | [{"t":0,"joints":{"head_tilt":0}},{"t":500,"joints":{"head_tilt":-30}},{"t":1500,"joints":{"head_tilt":0}}] |
|
||||
| nod | [{"t":0,"joints":{"head_tilt":0}},{"t":200,"joints":{"head_tilt":-15}},{"t":400,"joints":{"head_tilt":10}},{"t":600,"joints":{"head_tilt":0}}] |
|
||||
|
||||
## Complete Example: Reception Robot
|
||||
|
||||
### Package Structure
|
||||
|
||||
| Path | Description |
|
||||
|------|-------------|
|
||||
| `reception.gbai/` | Root package |
|
||||
| `reception.gbdialog/` | BASIC scripts |
|
||||
| `reception.gbdialog/start.bas` | Initialization and event registration |
|
||||
| `reception.gbdialog/tools/` | Tool definitions |
|
||||
| `reception.gbdialog/handlers/` | Event handlers |
|
||||
| `reception.gbot/` | Configuration |
|
||||
| `reception.gbot/robot.csv` | Robot settings |
|
||||
| `reception.gbot/servos.csv` | Servo mapping |
|
||||
| `reception.gbot/events.csv` | Event registration |
|
||||
| `reception.gbkb/` | Knowledge base |
|
||||
|
||||
### start.bas - Initialization
|
||||
|
||||
```basic
|
||||
' reception.gbdialog/start.bas
|
||||
' Initialize the reception robot
|
||||
|
||||
' Configure robot hardware
|
||||
SERVO INIT "PCA9685", address: 0x40
|
||||
ROBOT POSE "stand"
|
||||
ROBOT BALANCE ON
|
||||
|
||||
' Set personality for LLM
|
||||
SET SYSTEM PROMPT "You are a friendly reception robot at TechCorp. " + _
|
||||
"Greet visitors warmly, answer questions about the company, " + _
|
||||
"and direct them to the right department. " + _
|
||||
"Use your movement tools to be expressive and helpful."
|
||||
|
||||
' Load company knowledge
|
||||
USE KB "company-info"
|
||||
|
||||
' Register all tools for LLM
|
||||
USE TOOL "wave-hello"
|
||||
USE TOOL "point-direction"
|
||||
USE TOOL "bow-greeting"
|
||||
USE TOOL "walk-to-location"
|
||||
USE TOOL "show-emotion"
|
||||
USE TOOL "follow-person"
|
||||
|
||||
' Register event handlers
|
||||
ON CV "person" DETECTED CALL handlers/on-person-detected.bas
|
||||
ON CV "face" RECOGNIZED CALL handlers/on-face-recognized.bas
|
||||
ON CV "gesture:wave" DETECTED CALL handlers/on-wave-detected.bas
|
||||
ON HEAR CALL handlers/on-speech.bas
|
||||
ON IMU TILT > 15 CALL handlers/on-balance-issue.bas
|
||||
ON BATTERY < 20 CALL handlers/on-low-battery.bas
|
||||
|
||||
' Start with a ready pose
|
||||
TALK "Reception robot online and ready to help!"
|
||||
USE TOOL "show-emotion", emotion: "happy"
|
||||
```
|
||||
|
||||
### handlers/on-person-detected.bas
|
||||
|
||||
```basic
|
||||
' Called when a person enters the field of view
|
||||
|
||||
person = EVENT.data
|
||||
|
||||
' Face the person
|
||||
ROBOT HEAD "look", pan: person.direction.x, tilt: person.direction.y
|
||||
|
||||
' Greet appropriately
|
||||
IF person.identity <> "unknown" THEN
|
||||
' Known person
|
||||
TALK "Welcome back, " + person.identity + "! Great to see you again."
|
||||
USE TOOL "wave-hello", person_name: person.identity
|
||||
ELSE
|
||||
' New visitor
|
||||
TALK "Hello! Welcome to TechCorp. How may I assist you today?"
|
||||
USE TOOL "bow-greeting", style: "casual"
|
||||
END IF
|
||||
```
|
||||
|
||||
### handlers/on-face-recognized.bas
|
||||
|
||||
```basic
|
||||
' Called when a known face is recognized
|
||||
|
||||
face = EVENT.data
|
||||
|
||||
' Get person info from database
|
||||
person_info = GET "employees", "name = '" + face.identity + "'"
|
||||
|
||||
IF person_info THEN
|
||||
' Employee
|
||||
TALK "Good morning, " + face.identity + "! " + _
|
||||
"You have " + person_info.meetings_today + " meetings today."
|
||||
ELSE
|
||||
' Known visitor
|
||||
TALK "Hello " + face.identity + "! Let me notify your contact that you've arrived."
|
||||
SEND NOTIFICATION face.expected_contact, face.identity + " has arrived at reception"
|
||||
END IF
|
||||
```
|
||||
|
||||
### handlers/on-speech.bas
|
||||
|
||||
```basic
|
||||
' Called when speech is detected
|
||||
|
||||
speech = EVENT.data.text
|
||||
|
||||
' Use LLM with tools to generate response and actions
|
||||
' LLM will automatically call appropriate tools based on context:
|
||||
' - "Where is the bathroom?" → point-direction tool
|
||||
' - "Take me to the elevator" → walk-to-location + follow-person tools
|
||||
' - "Thank you!" → show-emotion + wave-hello tools
|
||||
|
||||
response = LLM speech
|
||||
TALK response
|
||||
```
|
||||
|
||||
### tools/guide-visitor.bas
|
||||
|
||||
```basic
|
||||
' guide-visitor.bas
|
||||
PARAM destination DESCRIPTION "Where to guide the visitor: meeting_room_a, meeting_room_b, cafeteria, restroom, elevator"
|
||||
PARAM visitor_name DESCRIPTION "Name of the visitor being guided"
|
||||
|
||||
TALK "Of course, " + visitor_name + "! Please follow me to " + destination + "."
|
||||
USE TOOL "show-emotion", emotion: "happy"
|
||||
|
||||
' Start walking and ask them to follow
|
||||
ROBOT MODE "guide"
|
||||
USE TOOL "walk-to-location", location: destination
|
||||
|
||||
' Arrived
|
||||
ROBOT TURN 180
|
||||
TALK "Here we are! This is the " + destination + ". Is there anything else you need?"
|
||||
USE TOOL "bow-greeting", style: "casual"
|
||||
```
|
||||
|
||||
## Build Guides
|
||||
|
||||
### Beginner: Desktop Companion (~$600)
|
||||
|
||||
| Component | Model | Price |
|
||||
|-----------|-------|-------|
|
||||
| Robot Kit | ROBOTIS MINI | $500 |
|
||||
| Compute | Raspberry Pi 5 4GB | $60 |
|
||||
| Camera | Pi Camera v3 | $25 |
|
||||
| Microphone | USB mic | $15 |
|
||||
|
||||
**Capabilities:** Voice conversation via cloud LLM, basic face detection, gesture responses, desktop assistant.
|
||||
|
||||
### Intermediate: Service Robot (~$10,000)
|
||||
|
||||
| Component | Model | Price |
|
||||
|-----------|-------|-------|
|
||||
| Robot Kit | Poppy Humanoid | $8,000 |
|
||||
| Compute | Jetson Orin Nano | $500 |
|
||||
| Camera | Intel RealSense D435 | $300 |
|
||||
| Microphone | ReSpeaker Array | $100 |
|
||||
| Speakers | USB powered | $50 |
|
||||
|
||||
**Capabilities:** Local LLM (Llama 3.2 3B), full body tracking, object manipulation, walking and navigation.
|
||||
|
||||
### Advanced: Research Platform (~$20,000+)
|
||||
|
||||
| Component | Model | Price |
|
||||
|-----------|-------|-------|
|
||||
| Robot Kit | Unitree G1 EDU | $16,000 |
|
||||
| Compute | Onboard + Workstation | $3,000 |
|
||||
| Sensors | LiDAR + Depth cameras | $1,000 |
|
||||
|
||||
**Capabilities:** Full autonomous navigation, complex manipulation, multi-modal interaction, research-grade motion control.
|
||||
|
||||
## Deployment Notes
|
||||
|
||||
### The Robot as a Server
|
||||
|
||||
When you deploy GB to a humanoid, you're deploying a server that happens to have legs. The robot:
|
||||
|
||||
- Has its own IP address on the network
|
||||
- Runs the full botserver API (REST, WebSocket)
|
||||
- Can be managed remotely via the Suite UI
|
||||
- Stores conversation history locally
|
||||
- Syncs with cloud when connected (optional)
|
||||
|
||||
Multiple robots can share a central botserver, or each can run independently. For a fleet of reception robots, you might run one botserver with multiple robot clients. For a standalone assistant, everything runs on the robot itself.
|
||||
|
||||
### Offline Operation
|
||||
|
||||
With llama.cpp and local models, the robot operates without internet:
|
||||
|
||||
| Model | RAM Required | Performance |
|
||||
|-------|--------------|-------------|
|
||||
| TinyLlama 1.1B | 2GB | ~5 tok/s on Pi 5 |
|
||||
| Phi-2 2.7B | 4GB | ~3 tok/s on Jetson |
|
||||
| Llama 3.2 3B | 6GB | ~4 tok/s on Orin Nano |
|
||||
|
||||
Vision models run locally via ONNX. The robot sees, thinks, and acts without phoning home.
|
||||
|
||||
## Safety
|
||||
|
||||
### Physical Safety
|
||||
|
||||
- Always have emergency stop accessible
|
||||
- Set conservative torque limits initially
|
||||
- Test movements at reduced speed first
|
||||
- Ensure stable base before walking
|
||||
- Keep clear area around robot
|
||||
|
||||
### Software Safety with Events
|
||||
|
||||
```basic
|
||||
' on-emergency.bas
|
||||
' Called by hardware emergency button or voice command
|
||||
|
||||
ROBOT STOP
|
||||
ROBOT POSE "safe"
|
||||
ROBOT BALANCE OFF
|
||||
LOG ERROR "Emergency stop activated"
|
||||
TALK "Emergency stop. All movement halted."
|
||||
```
|
||||
|
||||
Register in events.csv:
|
||||
|
||||
| event | handler | enabled |
|
||||
|-------|---------|---------|
|
||||
| EMERGENCY | on-emergency.bas | true |
|
||||
| HEAR:stop:emergency | on-emergency.bas | true |
|
||||
|
||||
### Operating Guidelines
|
||||
|
||||
| Situation | Event | Action |
|
||||
|-----------|-------|--------|
|
||||
| Unknown obstacle | ON DISTANCE < 0.5 | Stop, assess, navigate around |
|
||||
| Balance issue | ON IMU TILT > 15 | Widen stance or sit down |
|
||||
| Person too close | ON CV "person" DISTANCE < 0.8 | Step back, warn verbally |
|
||||
| Battery low | ON BATTERY < 20 | Announce, navigate to charger |
|
||||
| Communication lost | ON CONNECTION LOST | Safe pose, wait for reconnect |
|
||||
|
||||
## Resources
|
||||
|
||||
### Robot Kits
|
||||
|
||||
- [Unitree Robotics](https://www.unitree.com/) - G1, H1 humanoids
|
||||
- [ROBOTIS](https://www.robotis.com/) - OP3, MINI, Dynamixel
|
||||
- [Poppy Project](https://www.poppy-project.org/) - Open source humanoid
|
||||
- [InMoov](https://inmoov.fr/) - 3D printable humanoid
|
||||
- [Pollen Robotics](https://www.pollen-robotics.com/) - Reachy
|
||||
|
||||
### Components
|
||||
|
||||
- [Dynamixel](https://www.robotis.us/dynamixel/) - Smart servos
|
||||
- [ODrive](https://odriverobotics.com/) - BLDC motor control
|
||||
- [Intel RealSense](https://www.intelrealsense.com/) - Depth cameras
|
||||
- [NVIDIA Jetson](https://developer.nvidia.com/embedded/jetson-modules) - Edge AI
|
||||
|
||||
### Learning
|
||||
|
||||
- [ROS 2 Humanoid](https://docs.ros.org/) - Robot Operating System
|
||||
- [MoveIt](https://moveit.ros.org/) - Motion planning
|
||||
- [OpenCV](https://opencv.org/) - Computer vision
|
||||
- [MediaPipe](https://mediapipe.dev/) - Body/hand tracking
|
||||
|
|
@ -22,7 +22,7 @@ cd botserver
|
|||
```
|
||||
|
||||
That's it! After ~10-15 minutes:
|
||||
- BotServer runs on port 8088
|
||||
- botserver runs on port 8088
|
||||
- llama.cpp runs on port 8080 with TinyLlama
|
||||
- Embedded UI available at `http://your-device:8088/embedded/`
|
||||
|
||||
|
|
|
|||
|
|
@ -45,7 +45,7 @@ USE WEBSITE "https://sharepoint.company.com/docs"
|
|||
| Phase | Duration | Activities |
|
||||
|-------|----------|------------|
|
||||
| **Assessment** | Week 1-2 | Inventory services, identify dependencies |
|
||||
| **Infrastructure** | Week 2-3 | Deploy BotServer, configure auth/storage |
|
||||
| **Infrastructure** | Week 2-3 | Deploy botserver, configure auth/storage |
|
||||
| **Data Migration** | Week 3-6 | Users, email, files, documents |
|
||||
| **Process Migration** | Week 6-8 | Convert workflows to .gbdialog |
|
||||
| **Validation** | Week 8-10 | Testing, training, documentation |
|
||||
|
|
|
|||
|
|
@ -31,7 +31,7 @@ The General Bots testing framework is designed with a multi-layered, isolated ap
|
|||
│ │ │
|
||||
▼ ▼ ▼
|
||||
┌─────────┐ ┌─────────┐ ┌──────────┐
|
||||
│BotServer│ │ Browser│ │ Services │
|
||||
│botserver│ │ Browser│ │ Services │
|
||||
│(Testing)│ │ (WebDrv)│ │(Mock/Iso)│
|
||||
└─────────┘ └─────────┘ └──────────┘
|
||||
│ │ │
|
||||
|
|
@ -109,7 +109,7 @@ async fn test_message_storage_and_retrieval() {
|
|||
|
||||
**Phases**:
|
||||
1. Platform Loading
|
||||
2. BotServer Initialization
|
||||
2. botserver Initialization
|
||||
3. User Authentication
|
||||
4. Chat Interaction
|
||||
5. Logout & Session Management
|
||||
|
|
@ -160,7 +160,7 @@ Provides complete environment for E2E testing:
|
|||
```rust
|
||||
pub struct E2ETestContext {
|
||||
pub ctx: TestContext,
|
||||
pub server: BotServerInstance,
|
||||
pub server: botserverInstance,
|
||||
pub browser: Option<Browser>,
|
||||
}
|
||||
|
||||
|
|
@ -211,7 +211,7 @@ Each test gets dedicated service instances:
|
|||
- **Database**: Separate PostgreSQL cluster on port 5433
|
||||
- **Cache**: Separate Redis instance on port 6380
|
||||
- **Storage**: Separate MinIO instance on port 9001
|
||||
- **API**: Separate BotServer on port 8000
|
||||
- **API**: Separate botserver on port 8000
|
||||
|
||||
### Network Isolation
|
||||
|
||||
|
|
|
|||
|
|
@ -7,7 +7,7 @@ End-to-end (E2E) testing validates complete user workflows from platform loading
|
|||
E2E tests simulate real user interactions:
|
||||
|
||||
1. **Platform Loading** - UI and API infrastructure operational
|
||||
2. **BotServer Initialization** - Backend service running and ready
|
||||
2. **botserver Initialization** - Backend service running and ready
|
||||
3. **User Authentication** - Login workflow functional
|
||||
4. **Chat Interaction** - Message sending and receiving
|
||||
5. **Logout** - Session management and access control
|
||||
|
|
@ -26,7 +26,7 @@ async fn test_complete_platform_flow_login_chat_logout() {
|
|||
// Phase 1: Platform Loading
|
||||
verify_platform_loading(&ctx).await?;
|
||||
|
||||
// Phase 2: BotServer Running
|
||||
// Phase 2: botserver Running
|
||||
verify_botserver_running(&ctx).await?;
|
||||
|
||||
// Phase 3: User Login
|
||||
|
|
@ -58,7 +58,7 @@ Checks:
|
|||
- Database migrations completed
|
||||
- Services are initialized
|
||||
|
||||
### Phase 2: BotServer Initialization
|
||||
### Phase 2: botserver Initialization
|
||||
|
||||
Verifies the backend service is operational:
|
||||
|
||||
|
|
@ -129,7 +129,7 @@ cd gb/bottest
|
|||
# Platform loading verification
|
||||
cargo test --test e2e test_platform_loading_http_only -- --nocapture
|
||||
|
||||
# BotServer startup verification
|
||||
# botserver startup verification
|
||||
cargo test --test e2e test_botserver_startup -- --nocapture
|
||||
```
|
||||
|
||||
|
|
@ -210,7 +210,7 @@ Reusable helper functions for custom tests:
|
|||
// Verify platform is operational
|
||||
verify_platform_loading(&ctx) -> Result<()>
|
||||
|
||||
// Verify BotServer is running
|
||||
// Verify botserver is running
|
||||
verify_botserver_running(&ctx) -> Result<()>
|
||||
|
||||
// Perform login with credentials
|
||||
|
|
@ -331,7 +331,7 @@ Typical execution times:
|
|||
| Test | Time | Resources |
|
||||
|------|------|-----------|
|
||||
| Platform loading (HTTP-only) | ~2s | Minimal |
|
||||
| BotServer startup (HTTP-only) | ~5s | Minimal |
|
||||
| botserver startup (HTTP-only) | ~5s | Minimal |
|
||||
| Login and chat flow | ~20s | Browser + Memory |
|
||||
| Complete flow with all phases | ~45s | Browser + Memory |
|
||||
| Full E2E test suite | ~2-3 min | High |
|
||||
|
|
@ -366,7 +366,7 @@ jobs:
|
|||
|
||||
## Temporary Stack Architecture (Future)
|
||||
|
||||
When BotServer implements `--temp-stack`, E2E tests will run in isolated environments:
|
||||
When botserver implements `--temp-stack`, E2E tests will run in isolated environments:
|
||||
|
||||
```bash
|
||||
botserver --temp-stack
|
||||
|
|
@ -431,7 +431,7 @@ mod my_feature;
|
|||
## Test Success Criteria
|
||||
|
||||
✓ Platform fully loads without errors
|
||||
✓ BotServer starts and becomes ready
|
||||
✓ botserver starts and becomes ready
|
||||
✓ User can login with credentials
|
||||
✓ Chat messages are sent and responses received
|
||||
✓ User can logout and session is invalidated
|
||||
|
|
|
|||
|
|
@ -10,7 +10,7 @@ A complete General Bots deployment typically includes:
|
|||
|
||||
| Component | Purpose | Providers Supported |
|
||||
|-----------|---------|---------------------|
|
||||
| **Hosting** | Run BotServer | Any VPS, LXC, bare metal |
|
||||
| **Hosting** | Run botserver | Any VPS, LXC, bare metal |
|
||||
| **DNS** | Domain management | Namecheap, Cloudflare, Route53 |
|
||||
| **MDA** | Email delivery | Stalwart, Postfix, external SMTP |
|
||||
| **AI/LLM** | Language models | OpenAI, Anthropic, local models |
|
||||
|
|
@ -261,7 +261,7 @@ DNS SET domain, "TXT", "v=spf1 mx a ip4:" + server_ip + " -all"
|
|||
PRINT "DNS configured for " + domain
|
||||
```
|
||||
|
||||
### 3. Start BotServer
|
||||
### 3. Start botserver
|
||||
|
||||
```bash
|
||||
./botserver
|
||||
|
|
@ -312,7 +312,7 @@ PRINT "Email sent successfully"
|
|||
1. Verify `llm-url` in config.csv
|
||||
2. Check API key in Vault
|
||||
3. Test endpoint with curl
|
||||
4. Review BotServer logs
|
||||
4. Review botserver logs
|
||||
|
||||
---
|
||||
|
||||
|
|
|
|||
|
|
@ -1,10 +1,10 @@
|
|||
# Chapter 19: Maintenance and Updates
|
||||
|
||||
BotServer includes a complete stack of self-hosted services that power your bots. This chapter covers how to maintain, update, and troubleshoot these components.
|
||||
botserver includes a complete stack of self-hosted services that power your bots. This chapter covers how to maintain, update, and troubleshoot these components.
|
||||
|
||||
## Stack Components Overview
|
||||
|
||||
BotServer automatically installs and manages these services:
|
||||
botserver automatically installs and manages these services:
|
||||
|
||||
| Component | Service | Default Port | Purpose |
|
||||
|-----------|---------|--------------|---------|
|
||||
|
|
|
|||
|
|
@ -1,6 +1,6 @@
|
|||
# Backup and Recovery
|
||||
|
||||
Protecting your BotServer data requires regular backups of databases, configurations, and file storage. This guide covers backup strategies, procedures, and disaster recovery.
|
||||
Protecting your botserver data requires regular backups of databases, configurations, and file storage. This guide covers backup strategies, procedures, and disaster recovery.
|
||||
|
||||
---
|
||||
|
||||
|
|
@ -259,7 +259,7 @@ fi
|
|||
# Create manifest
|
||||
echo "Creating manifest..."
|
||||
cat > "$BACKUP_DIR/manifest.txt" << EOF
|
||||
BotServer Backup
|
||||
botserver Backup
|
||||
Date: $(date)
|
||||
Host: $(hostname)
|
||||
|
||||
|
|
@ -295,7 +295,7 @@ Add to crontab:
|
|||
|
||||
### Recovery Procedure
|
||||
|
||||
1. **Install fresh BotServer**
|
||||
1. **Install fresh botserver**
|
||||
```bash
|
||||
./botserver --skip-bootstrap
|
||||
```
|
||||
|
|
|
|||
|
|
@ -1,6 +1,6 @@
|
|||
# Component Reference
|
||||
|
||||
This reference provides detailed information about each component in the BotServer stack, including current versions, alternatives, and configuration options.
|
||||
This reference provides detailed information about each component in the botserver stack, including current versions, alternatives, and configuration options.
|
||||
|
||||
---
|
||||
|
||||
|
|
|
|||
Some files were not shown because too many files have changed in this diff Show more
Loading…
Add table
Reference in a new issue