Unify agent entry point with natural language routing

[cpetersen]

Summary

Eliminates the split between /query (RAG) and /code (agent) — all input now goes through a single Agent that decides whether to search documents or write code based on natural language.

SearchDocs Tool

• Wraps the RAG retrieval pipeline as a RubyLLM::Tool
• Returns retrieved context + sources (not LLM-generated answer) so the Agent synthesizes its own response — avoids double-LLM problem
• New retrieve_context public method on QueryProcessor (DRY extraction of steps 1-5)

Unified Default Handler

• TUI routes all natural language input through a cached Agent + Orchestrator
• "What is our password policy?" → Agent calls search_docs
• "Create fizzbuzz.rb and run it" → Agent uses write_file + bash_exec
• /query and /code still work as explicit alternatives

Lite Tool Set for Local Models

• Small local models (Qwen3-8B) get overwhelmed with 9 tools + long descriptions — they output only <think> blocks
• Lite set: 4 tools with minimal descriptions (LiteReadFile, LiteWriteFile, LiteBashExec, LiteTaskComplete)
• Agent auto-selects: red_candle → LITE (4 tools), cloud providers → ALL (9 tools)
• Tested: Qwen3-8B successfully writes files, runs bash, and calls task_complete through the full loop

Other

• Profile switching clears cached agent/orchestrator
• /no_think added to Agent system prompt
• System prompt guides LLM on when to use knowledge base vs coding tools

Test plan

• 392 specs, 0 failures
• Qwen3-8B with lite tools: writes files, runs commands, calls task_complete
• Opus with full tools: all 9 tools work
• /query and /code still work as explicit commands
• Profile switching clears and rebuilds agent

🤖 Generated with Claude Code