feat: Phase 5.3 - Multi-Agent Learning Infrastructure
Implement intelligent agent learning from Knowledge Graph execution history
with per-task-type expertise tracking, recency bias, and learning curves.
## Phase 5.3 Implementation
### Learning Infrastructure (✅ Complete)
- LearningProfileService with per-task-type expertise metrics
- TaskTypeExpertise model tracking success_rate, confidence, learning curves
- Recency bias weighting: recent 7 days weighted 3x higher (exponential decay)
- Confidence scoring prevents overfitting: min(1.0, executions / 20)
- Learning curves computed from daily execution windows
### Agent Scoring Service (✅ Complete)
- Unified AgentScore combining SwarmCoordinator + learning profiles
- Scoring formula: 0.3*base + 0.5*expertise + 0.2*confidence
- Rank agents by combined score for intelligent assignment
- Support for recency-biased scoring (recent_success_rate)
- Methods: rank_agents, select_best, rank_agents_with_recency
### KG Integration (✅ Complete)
- KGPersistence::get_executions_for_task_type() - query by agent + task type
- KGPersistence::get_agent_executions() - all executions for agent
- Coordinator::load_learning_profile_from_kg() - core KG→Learning integration
- Coordinator::load_all_learning_profiles() - batch load for multiple agents
- Convert PersistedExecution → ExecutionData for learning calculations
### Agent Assignment Integration (✅ Complete)
- AgentCoordinator uses learning profiles for task assignment
- extract_task_type() infers task type from title/description
- assign_task() scores candidates using AgentScoringService
- Fallback to load-based selection if no learning data available
- Learning profiles stored in coordinator.learning_profiles RwLock
### Profile Adapter Enhancements (✅ Complete)
- create_learning_profile() - initialize empty profiles
- add_task_type_expertise() - set task-type expertise
- update_profile_with_learning() - update swarm profiles from learning
## Files Modified
### vapora-knowledge-graph/src/persistence.rs (+30 lines)
- get_executions_for_task_type(agent_id, task_type, limit)
- get_agent_executions(agent_id, limit)
### vapora-agents/src/coordinator.rs (+100 lines)
- load_learning_profile_from_kg() - core KG integration method
- load_all_learning_profiles() - batch loading for agents
- assign_task() already uses learning-based scoring via AgentScoringService
### Existing Complete Implementation
- vapora-knowledge-graph/src/learning.rs - calculation functions
- vapora-agents/src/learning_profile.rs - data structures and expertise
- vapora-agents/src/scoring.rs - unified scoring service
- vapora-agents/src/profile_adapter.rs - adapter methods
## Tests Passing
- learning_profile: 7 tests ✅
- scoring: 5 tests ✅
- profile_adapter: 6 tests ✅
- coordinator: learning-specific tests ✅
## Data Flow
1. Task arrives → AgentCoordinator::assign_task()
2. Extract task_type from description
3. Query KG for task-type executions (load_learning_profile_from_kg)
4. Calculate expertise with recency bias
5. Score candidates (SwarmCoordinator + learning)
6. Assign to top-scored agent
7. Execution result → KG → Update learning profiles
## Key Design Decisions
✅ Recency bias: 7-day half-life with 3x weight for recent performance
✅ Confidence scoring: min(1.0, total_executions / 20) prevents overfitting
✅ Hierarchical scoring: 30% base load, 50% expertise, 20% confidence
✅ KG query limit: 100 recent executions per task-type for performance
✅ Async loading: load_learning_profile_from_kg supports concurrent loads
## Next: Phase 5.4 - Cost Optimization
Ready to implement budget enforcement and cost-aware provider selection.
2026-01-11 13:03:53 +00:00
|
|
|
// Integration tests for VAPORA backend
|
|
|
|
|
// These tests verify the complete API functionality
|
|
|
|
|
|
|
|
|
|
use axum::http::StatusCode;
|
|
|
|
|
use axum_test::TestServer;
|
|
|
|
|
use chrono::Utc;
|
2026-01-11 21:32:56 +00:00
|
|
|
use vapora_shared::models::{
|
|
|
|
|
Agent, AgentRole, AgentStatus, Project, ProjectStatus, Task, TaskPriority, TaskStatus,
|
|
|
|
|
};
|
feat: Phase 5.3 - Multi-Agent Learning Infrastructure
Implement intelligent agent learning from Knowledge Graph execution history
with per-task-type expertise tracking, recency bias, and learning curves.
## Phase 5.3 Implementation
### Learning Infrastructure (✅ Complete)
- LearningProfileService with per-task-type expertise metrics
- TaskTypeExpertise model tracking success_rate, confidence, learning curves
- Recency bias weighting: recent 7 days weighted 3x higher (exponential decay)
- Confidence scoring prevents overfitting: min(1.0, executions / 20)
- Learning curves computed from daily execution windows
### Agent Scoring Service (✅ Complete)
- Unified AgentScore combining SwarmCoordinator + learning profiles
- Scoring formula: 0.3*base + 0.5*expertise + 0.2*confidence
- Rank agents by combined score for intelligent assignment
- Support for recency-biased scoring (recent_success_rate)
- Methods: rank_agents, select_best, rank_agents_with_recency
### KG Integration (✅ Complete)
- KGPersistence::get_executions_for_task_type() - query by agent + task type
- KGPersistence::get_agent_executions() - all executions for agent
- Coordinator::load_learning_profile_from_kg() - core KG→Learning integration
- Coordinator::load_all_learning_profiles() - batch load for multiple agents
- Convert PersistedExecution → ExecutionData for learning calculations
### Agent Assignment Integration (✅ Complete)
- AgentCoordinator uses learning profiles for task assignment
- extract_task_type() infers task type from title/description
- assign_task() scores candidates using AgentScoringService
- Fallback to load-based selection if no learning data available
- Learning profiles stored in coordinator.learning_profiles RwLock
### Profile Adapter Enhancements (✅ Complete)
- create_learning_profile() - initialize empty profiles
- add_task_type_expertise() - set task-type expertise
- update_profile_with_learning() - update swarm profiles from learning
## Files Modified
### vapora-knowledge-graph/src/persistence.rs (+30 lines)
- get_executions_for_task_type(agent_id, task_type, limit)
- get_agent_executions(agent_id, limit)
### vapora-agents/src/coordinator.rs (+100 lines)
- load_learning_profile_from_kg() - core KG integration method
- load_all_learning_profiles() - batch loading for agents
- assign_task() already uses learning-based scoring via AgentScoringService
### Existing Complete Implementation
- vapora-knowledge-graph/src/learning.rs - calculation functions
- vapora-agents/src/learning_profile.rs - data structures and expertise
- vapora-agents/src/scoring.rs - unified scoring service
- vapora-agents/src/profile_adapter.rs - adapter methods
## Tests Passing
- learning_profile: 7 tests ✅
- scoring: 5 tests ✅
- profile_adapter: 6 tests ✅
- coordinator: learning-specific tests ✅
## Data Flow
1. Task arrives → AgentCoordinator::assign_task()
2. Extract task_type from description
3. Query KG for task-type executions (load_learning_profile_from_kg)
4. Calculate expertise with recency bias
5. Score candidates (SwarmCoordinator + learning)
6. Assign to top-scored agent
7. Execution result → KG → Update learning profiles
## Key Design Decisions
✅ Recency bias: 7-day half-life with 3x weight for recent performance
✅ Confidence scoring: min(1.0, total_executions / 20) prevents overfitting
✅ Hierarchical scoring: 30% base load, 50% expertise, 20% confidence
✅ KG query limit: 100 recent executions per task-type for performance
✅ Async loading: load_learning_profile_from_kg supports concurrent loads
## Next: Phase 5.4 - Cost Optimization
Ready to implement budget enforcement and cost-aware provider selection.
2026-01-11 13:03:53 +00:00
|
|
|
|
|
|
|
|
/// Helper function to create a test project
|
|
|
|
|
fn create_test_project() -> Project {
|
|
|
|
|
Project {
|
|
|
|
|
id: None,
|
|
|
|
|
tenant_id: "test-tenant".to_string(),
|
|
|
|
|
title: "Test Project".to_string(),
|
|
|
|
|
description: Some("A test project".to_string()),
|
|
|
|
|
status: ProjectStatus::Active,
|
|
|
|
|
features: vec!["feature1".to_string()],
|
|
|
|
|
created_at: Utc::now(),
|
|
|
|
|
updated_at: Utc::now(),
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/// Helper function to create a test task
|
|
|
|
|
fn create_test_task(project_id: String) -> Task {
|
|
|
|
|
Task {
|
|
|
|
|
id: None,
|
|
|
|
|
tenant_id: "test-tenant".to_string(),
|
|
|
|
|
project_id,
|
|
|
|
|
title: "Test Task".to_string(),
|
|
|
|
|
description: Some("A test task".to_string()),
|
|
|
|
|
status: TaskStatus::Todo,
|
|
|
|
|
assignee: "unassigned".to_string(),
|
|
|
|
|
priority: TaskPriority::Medium,
|
|
|
|
|
task_order: 0,
|
|
|
|
|
feature: Some("feature1".to_string()),
|
|
|
|
|
created_at: Utc::now(),
|
|
|
|
|
updated_at: Utc::now(),
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/// Helper function to create a test agent
|
|
|
|
|
fn create_test_agent() -> Agent {
|
|
|
|
|
Agent {
|
|
|
|
|
id: "test-agent-1".to_string(),
|
|
|
|
|
role: AgentRole::Developer,
|
|
|
|
|
name: "Test Developer Agent".to_string(),
|
|
|
|
|
version: "1.0.0".to_string(),
|
|
|
|
|
status: AgentStatus::Active,
|
|
|
|
|
capabilities: vec!["rust".to_string(), "async".to_string()],
|
|
|
|
|
skills: vec!["backend".to_string()],
|
|
|
|
|
llm_provider: "claude".to_string(),
|
|
|
|
|
llm_model: "claude-sonnet-4".to_string(),
|
|
|
|
|
max_concurrent_tasks: 3,
|
|
|
|
|
created_at: Utc::now(),
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
#[tokio::test]
|
|
|
|
|
async fn test_health_endpoint() {
|
|
|
|
|
// Note: This test doesn't require a running server
|
|
|
|
|
// It's a placeholder for actual integration tests
|
|
|
|
|
// Real tests would use TestServer and require SurrealDB to be running
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
#[tokio::test]
|
|
|
|
|
async fn test_project_lifecycle() {
|
|
|
|
|
// Note: This test requires a running SurrealDB instance
|
|
|
|
|
// For now, it's a placeholder demonstrating the test structure
|
|
|
|
|
// Real implementation would:
|
|
|
|
|
// 1. Create a TestServer with the app
|
|
|
|
|
// 2. POST /api/v1/projects - create project
|
|
|
|
|
// 3. GET /api/v1/projects/:id - verify creation
|
|
|
|
|
// 4. PUT /api/v1/projects/:id - update project
|
|
|
|
|
// 5. DELETE /api/v1/projects/:id - delete project
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
#[tokio::test]
|
|
|
|
|
async fn test_task_lifecycle() {
|
|
|
|
|
// Note: Placeholder test
|
|
|
|
|
// Real implementation would test:
|
|
|
|
|
// 1. Create task
|
|
|
|
|
// 2. List tasks
|
|
|
|
|
// 3. Update task status
|
|
|
|
|
// 4. Reorder task
|
|
|
|
|
// 5. Delete task
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
#[tokio::test]
|
|
|
|
|
async fn test_agent_registration() {
|
|
|
|
|
// Note: Placeholder test
|
|
|
|
|
// Real implementation would test:
|
|
|
|
|
// 1. Register agent
|
|
|
|
|
// 2. List agents
|
|
|
|
|
// 3. Update agent status
|
|
|
|
|
// 4. Check agent health
|
|
|
|
|
// 5. Deregister agent
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
#[tokio::test]
|
|
|
|
|
async fn test_kanban_operations() {
|
|
|
|
|
// Note: Placeholder test
|
|
|
|
|
// Real implementation would test:
|
|
|
|
|
// 1. Create multiple tasks in different columns
|
|
|
|
|
// 2. Move task between columns
|
|
|
|
|
// 3. Reorder tasks within a column
|
|
|
|
|
// 4. Verify task order is maintained
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
#[tokio::test]
|
|
|
|
|
async fn test_error_handling() {
|
|
|
|
|
// Note: Placeholder test
|
|
|
|
|
// Real implementation would test:
|
|
|
|
|
// 1. Not found errors (404)
|
|
|
|
|
// 2. Invalid input errors (400)
|
|
|
|
|
// 3. Unauthorized errors (401)
|
|
|
|
|
// 4. Database errors (500)
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// Note: To run these tests properly, you would need:
|
|
|
|
|
// 1. A test SurrealDB instance running
|
|
|
|
|
// 2. Test fixtures and cleanup
|
|
|
|
|
// 3. TestServer setup from axum_test
|
|
|
|
|
//
|
|
|
|
|
// Example of a real test structure:
|
|
|
|
|
//
|
|
|
|
|
// #[tokio::test]
|
|
|
|
|
// async fn test_create_project_real() {
|
|
|
|
|
// let app = build_test_app().await;
|
|
|
|
|
// let server = TestServer::new(app).unwrap();
|
|
|
|
|
//
|
|
|
|
|
// let project = create_test_project();
|
|
|
|
|
// let response = server
|
|
|
|
|
// .post("/api/v1/projects")
|
|
|
|
|
// .json(&project)
|
|
|
|
|
// .await;
|
|
|
|
|
//
|
|
|
|
|
// assert_eq!(response.status_code(), StatusCode::CREATED);
|
|
|
|
|
// let created: Project = response.json();
|
|
|
|
|
// assert_eq!(created.title, project.title);
|
|
|
|
|
// }
|