- Updated get_tool_bas_path to look in /opt/gbo/data (source) first
- Then check botserver-stack/data/system/work (compiled) second
- Removed incorrect $HOME/data and $HOME/gb/work paths
- Fixes 'Tool file not found' error when executing inscricao tool
According to AGENTS.md architecture:
- Bots are in /opt/gbo/data primary
- They are compiled into work directory by local_file_monitor
- tool_executor was looking in wrong directories
- Add API endpoints to deployment/mod.rs:
- GET /api/deployment/targets - List available deployment targets
- POST /api/deployment/deploy - Deploy application to selected target
- Register deployment routes in main application router
- Support for internal GB Platform and external Forgejo deployments
- Proper error handling with ErrorSanitizer
- SQL injection protection with sql_guard
Phase 0: Deployment Infrastructure - COMPLETE ✅
Phase 1: Code Editor Integration
- Add Monaco Editor to vendor directory
- Create editor.html component with full Monaco integration
- Create API endpoints for file operations (editor.rs)
- GET /api/editor/file/:file_path - Read file
- POST /api/editor/file/:file_path - Save file
- GET /api/editor/files - List files
- Features:
- File tree sidebar
- Multi-file tabs
- Syntax highlighting for 10+ languages
- Auto-save with WebSocket sync preparation
- Keyboard shortcuts (Ctrl+S, Ctrl+P)
- Status bar with language, encoding, cursor position
- Custom GB dark theme
- Publish integration with deployment modal
- Add detailed logging for all 5 pipeline stages (PLAN, BUILD, REVIEW, DEPLOY, MONITOR)
- Log stage start/complete events with agent IDs and progress details
- Add resource creation/deletion logging in drive_handlers
- Improve pipeline summary logging with task ID, nodes, resources, and URL
This addresses the requirement for textual progress in console logs.
- Fix PAT extraction timing with retry loop (waits up to 60s for PAT in logs)
- Add sync command to flush filesystem buffers before extraction
- Improve logging with progress messages and PAT verification
- Refactor setup code into consolidated setup.rs module
- Fix YAML indentation for PatPath and MachineKeyPath
- Change Zitadel init parameter from --config to --steps
The timing issue occurred because:
1. Zitadel writes PAT to logs at startup (~18:08:59)
2. Post-install extraction ran too early (~18:09:35)
3. PAT file wasn't created until ~18:10:38 (63s after installation)
4. OAuth client creation failed because PAT file didn't exist yet
With the retry loop:
- Waits for PAT to appear in logs with sync+grep check
- Extracts PAT immediately when found
- OAuth client creation succeeds
- directory_config.json saved with valid credentials
- Login flow works end-to-end
Tested: Full reset.sh and login verification successful
- Updated error message to explain when credentials are found but invalid
- Clarified that credentials might be from a previous installation
- Added step-by-step solution for resetting credentials
- Removed misleading 'No admin credentials found' message
The error now accurately reflects the actual problem: authentication
failure rather than missing credentials.
- Added OAuth client creation to the 'already running' branch
- Previously, OAuth client was only created when Zitadel was started
- This fixes the issue where OAuth client wasn't created on subsequent runs
Fixes the OAuth client creation issue discovered during testing.
- Updated setup_directory() to read credentials from saved file
- Added read_saved_credentials() to parse ~/.gb-setup-credentials
- Added get_admin_credentials() to try multiple sources
- Removed default credentials approach (doesn't work)
- Improved error messages with solution steps
This matches the working approach from commit 86cfccc2 where
credentials were saved during first bootstrap and reused for
OAuth client creation on subsequent runs.
Fixed compilation errors by adding .await to all ensure_admin_token() calls:
- create_organization()
- create_user()
- save_config()
The method was made async but the calls weren't updated.
- Add password grant authentication support in DirectorySetup
- Extract initial admin credentials from Zitadel log file
- Fix race condition in Zitadel startup (wait for health check before starting)
- Create parent directories before saving config
- Add retry logic for OAuth client creation
- Improve error handling with detailed messages
Fixes authentication service not configured error after bootstrap.
Updated all hardcoded work/ directory references to use the correct
relative path from the current working directory:
- botserver-stack/data/system/work
This ensures consistent file location resolution regardless of where
botserver is run from (/home/rodriguez/src/gb/ or /opt/gbo/bin/).
Changes:
- local_file_monitor.rs: Use std::env::current_dir() for work_root
- drive_monitor/mod.rs: Use work_root PathBuf for tool compilation
- website_crawler_service.rs: Use std::env::current_dir() for work_path
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com>
Added logic to create botserver-stack/data/system/work directory
if it doesn't exist. This ensures production deployments work
without manual directory setup.
Changes:
- Added fs::create_dir_all() in use_tool.rs
- Added fs::create_dir_all() in tool_context.rs
- Logs when directory is created
- Fixes production deployment where /system/work may not exist
This ensures the tool loading works in fresh production environments
where the work folder hasn't been populated yet.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com>
Changed tool loading to use relative path from current directory instead
of hardcoded HOME/gb path. This makes the code portable across different
deployment environments.
- Updated use_tool.rs to use std::env::current_dir()
- Updated tool_context.rs to use std::env::current_dir()
- Added PathBuf import to both files
- Tools now load from botserver-stack/data/system/work/
Fixes issue where tools weren't being loaded because .mcp.json files
were in a different location than expected.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com>
- Fixed RCE vulnerability in trusted_shell_script_arg execution
- Fixed SSRF vulnerability in GET command with internal IP blocking
- Updated SafeCommand to use explicit positional arguments
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
- Track tool_was_executed flag in stream_response
- Send empty content in final is_complete message when tool already sent results
- Prevents the LLM's pre-tool text from appearing twice in the chat UI
- DB message saving is unaffected (uses full_response_clone before the check)
- Support # as comment marker like ' in BASIC preprocessor
- Remove hardcoded column lists from get_table_field_names()
- Let runtime use database schema dynamically via get_table_columns()
- Fix SELECT/CASE conversion to add semicolons to body statements
Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
- Change BOTSERVER_PORT to PORT for consistency with .env.embedded
- Update default port from 8080 to 9000 in config
- Fix service port references in security integration
- Update directory setup ExternalPort to 9000
Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
- Add tool_call_buffer to accumulate JSON chunks across multiple LLM responses
- Handle incomplete tool call JSON that spans multiple chunks
- Convert SELECT...CASE/END SELECT to Rhai match expressions
- Fix NOT IN operator conversion to !in for IF conditions
Fixed issue where LLM tool calls returned as JSON arrays were not being
detected and were displayed as raw JSON in the chat instead of being executed.
The parse_tool_call method now handles:
- Single tool call objects
- Arrays of tool calls (OpenAI standard format)
This prevents tool call JSON from appearing in the chat window and ensures
tools are executed properly.
Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
Add error and warning logs to help diagnose why session tools are not
working in production. Logs now show:
- Number of tools loaded successfully
- Detailed error messages when tool loading fails
- Bot name lookup failures
Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
Remove actions/checkout with custom path that causes multiple workspace
roots error. Clone botserver repository directly in Setup Workspace step
instead of using checkout action.
Fixes error: "multiple workspace roots found in the same workspace"
Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
This loads and sends the available tools to the client when establishing
a WebSocket connection. Tools are loaded based on the bot configuration
and sent in the initial welcome message.
Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
DeepSeek R1 model outputs reasoning_content first, then content.
With n_predict=50, responses were truncated during reasoning phase.
Increased to 512 to allow full reasoning + response.
Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
Changed default model from 'gpt-3.5-turbo' to 'DeepSeek-R1-Distill-Qwen-1.5B-Q3_K_M.gguf'
in bot message handler. This ensures the local llama-server receives the correct model
name and can process requests properly.
Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
- Change model paths to use ./data/llm/ instead of relative paths from build dir
- Remove cd command when starting llama-server to keep botserver root as cwd
- This fixes model loading when servers are started from different directories
- Both LLM and embedding servers now start successfully
Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
Modified get_bot_pool() to automatically create the database for a bot
if it doesn't exist, instead of failing with "No database configured" error.
This fixes the issue where bots created after the initial sync don't have
a database_name set in the bots table, causing table creation to fail.
Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
- Add vector_db_health_check() function to verify Qdrant availability
- Add wait loop for vector_db startup in bootstrap (15 seconds)
- Fallback to local LLM when external URL configured but no API key provided
- Prevent external LLM (api.z.ai) usage without authentication key
This fixes the production issues:
- Qdrant vector database not available at https://localhost:6333
- External LLM being used instead of local when no key is configured
- Ensures vector_db is properly started and ready before use
Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
The config_manager.get_config() can return Ok("") for empty config values,
which would pass through unwrap_or_else() without using the default.
Added checks after config retrieval to use defaults when config values
are empty strings:
- gpu_layers: "20" (default for GPU layers)
- n_moe: "4" (default for MoE)
- parallel: "1" (default for parallel)
- n_predict: "50" (default for predict)
- n_ctx_size: "32000" (default for context size)
This fixes the error: "error while handling argument --n-gpu-layers: stoi"
Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
When no default.gbai/config.csv exists, the system now:
- Sets default llm_server_path to ./botserver-stack/bin/llm/build/bin
- Uses correct relative paths to model files: ../../../../data/llm/
- Uses actual model filenames from 3rdparty.toml
This fixes the issue where LLM/embedding servers couldn't find model files
because the paths were constructed incorrectly.
Model filenames:
- LLM: DeepSeek-R1-Distill-Qwen-1.5B-Q3_K_M.gguf
- Embedding: bge-small-en-v1.5-f32.gguf
Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
Changed the default LLM model from glm-4 to deepseek-small to match
the model defined in 3rdparty.toml ([models.deepseek_small]).
This ensures that when no default.gbai/config.csv exists, the system
uses the correct default local model.
Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
When no default.gbai/config.csv exists or when llm-model/embedding-model
config is empty, the system now uses default local models instead of
skipping server startup.
Changes:
- Default LLM model: glm-4
- Default Embedding model: bge-small-en-v1.5
- Logs when using defaults
This fixes the issue where the "default" bot would fail to load LLM
and Embedding services when no config.csv was present, causing the
error: "not loading embedding neither llm local for default bot"
Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
The init_redis() function was using synchronous blocking calls
(redis::Client::get_connection()) inside an async function, which
blocked the entire tokio runtime and caused botserver to freeze.
Changes:
- Wrap Redis connection calls in tokio::task::spawn_blocking()
- Runs blocking operations in separate thread pool
- Prevents tokio runtime from freezing during cache connection
This fixes the issue where botserver would hang indefinitely
when connecting to Valkey/Redis cache.
Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
The previous /dev/tcp test was giving false positives, reporting that
Valkey was running when it was actually down. This caused bootstrap to
skip starting Valkey, leading to botserver hanging on cache connection.
Changes:
- Use nc (netcat) with -z flag for reliable port checking
- Final fallback: /dev/tcp with actual PING/PONG verification
- Only returns true if port is open AND responds correctly
This ensures cache_health_check() accurately reports Valkey status.
Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
- Try valkey-cli first (preferred for Valkey installations)
- Fall back to redis-cli (for Redis installations)
- Fall back to TCP connection test (works for both)
This fixes environments that only have Valkey installed without
Redis symlinks or redis-cli.
Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
- Fix component name mismatch: "redis" -> "cache" in bootstrap_manager
- Add cache_health_check() function to verify Valkey is responding
- Add health check loop after starting cache (12s wait with PING test)
- Ensures cache is ready before proceeding with bootstrap
This fixes the issue where botserver would hang waiting for cache
connection because the cache component was never started.
Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
- Binaries at cache/bin/valkey-server (correct production path)
- Use --strip-components=1 for extraction
- Matches /opt/gbo/bin/botserver-stack/bin/cache/bin/
Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
- Use --strip-components=2 to flatten tarball structure
- Binaries go to cache/valkey-server (not cache/bin/valkey-server)
- Matches production path: /opt/gbo/bin/botserver-stack/bin/cache/
Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
