Architecture: How should Vitto be restructured from a god-class embedded i...

Documentation for Sessions

🏗️ Architecture: How should Vitto be restructured from a god-class embedded i...

Date: 2026-02-07
Time: 18:10:49 UTC
Session: gspace1-98.2
Agent: backend
Confidence: 95%
Status: ✅ Documented

📋 Decision Context

Question:

How should Vitto be restructured from a god-class embedded in backend-ai-api?

Task: Vitto Super-Agent separation and rebuild

🎯 Decision Made

Chosen:

Extract Vitto into a standalone NX backend app (backend-vitto-api) on port 3003 with its own MongoDB (vitto-mind), provider-agnostic LLM abstraction, 4-phase workflow (ANALYZE->PLAN->EXECUTE->VERIFY), and full data access to all 3 backends via HTTP/WS

Options Considered:

Keep Vitto embedded in backend-ai-api and refactor in-place
Extract as NX library shared between apps
Build standalone API (backend-vitto-api) with own database
Use microservices with message queue

💭 Reasoning

The 2119-line VittoOrchestratorService was a god-class that auto-claimed handoffs and generated text without tools/quality checks. A standalone API provides: process isolation, independent scaling, own operational memory (Mind DB), provider flexibility (Claude/OpenAI/Gemini), and proper separation of concerns. The agentic process in backend-ai-api (HandoffService, AgentService, WebSocket) works independently — removing Vitto doesn't break anything.

📁 Files Involved

apis/backend-vitto-api/src/main.ts
apis/backend-vitto-api/src/app/app.module.ts
apis/backend-vitto-api/src/app/engine/vitto-engine.service.ts
apis/backend-vitto-api/src/app/engine/phase-executor.service.ts

🔗 Related

Decision ID: dev_1770487849759_9waf8kx
Session: 98
Workspace: gspace1

Auto-generated by MCP Smart Consolidation