test: added integration tests for inter-feature interactions like RAG + Agents, function calling/MCP servers, etc.

src/config/rag_cache.rs

@@ -1,29 +1,3 @@
-//! Per-process RAG instance cache with weak-reference sharing.
-//!
-//! `RagCache` lives on [`AppState`](super::AppState) and serves both
-//! standalone RAGs (attached via `.rag <name>`) and agent-owned RAGs
-//! (loaded from an agent's `documents:` field). The cache keys with
-//! [`RagKey`] so that agent RAGs and standalone RAGs occupy distinct
-//! namespaces even if they share a name.
-//!
-//! Entries are held as `Weak<Rag>` so the cache never keeps a RAG
-//! alive on its own — once all active scopes drop their `Arc<Rag>`,
-//! the cache entry becomes unupgradable and the next `load()` falls
-//! through to a fresh disk read.
-//!
-//! # Phase 1 Step 6.5 scope
-//!
-//! This file introduces the type scaffolding. Actual cache population
-//! (i.e., routing `use_rag`, `use_agent`, and sub-agent spawning
-//! through the cache) is deferred to Step 8 when the entry points get
-//! rewritten. During the bridge window, `Config.rag` keeps serving
-//! today's callers via direct `Rag::load` / `Rag::init` calls and
-//! `RagCache` sits on `AppState` as an unused-but-ready service.
-//!
-//! See `docs/REST-API-ARCHITECTURE.md` section 5 ("RAG Cache") for
-//! the full design including concurrent first-load serialization and
-//! invalidation semantics.
-
 use crate::rag::Rag;
 
 use anyhow::Result;