🏗️ Architecture: How to resolve the fundamental disconnect between Pipeline A...

Date: 2026-02-23
Time: 18:01:55 UTC
Session: gspace1-138.4
Agent: backend
Confidence: 92%
Status: ✅ Documented

📋 Decision Context

Question:

How to resolve the fundamental disconnect between Pipeline A (backend-ai-api/workflow, used by frontend) and Pipeline B (backend-vitto-api/module-generation, has Session 137 improvements but no frontend connection)?

Task: Pipeline unification strategy for S138

🎯 Decision Made

Chosen:

Wire frontend to Pipeline B — adapt workflow-state.service.ts to call /vitto-api/module-generation/generate via VITTO_API_URL, deprecate Pipeline A's generation orchestration, keep Pipeline A only for data storage/catalog

Options Considered:

1. Wire frontend to call Pipeline B directly and deprecate Pipeline A's generation logic
2. Port Session 137 improvements (auto-correction, route-generator, validate-fix, checkpoint) into Pipeline A
3. Create a unified pipeline combining both into a new service

💭 Reasoning

Root cause analysis reveals the disconnect is architectural debt from parallel development. Pipeline B is objectively superior: (1) Well-structured — 3376 lines across 16 specialized files vs Pipeline A's 1716-line monolith. (2) Full S137 improvements — auto-correction (12 regex rules), route generation, validate-fix loop, MongoDB checkpoint/resume, deploy phase. (3) Already has SSE support with proper event types and 30s heartbeat. (4) The hybrid state already exists — resumeWorkflow() in workflow-state.service.ts already calls VITTO_API_URL for Pipeline B. Starting workflows via Pipeline A but resuming via Pipeline B is inconsistent. (5) Pipeline B's DEPLOY phase already calls backend-ai-api internally for persistence. (6) Porting S137 improvements into Pipeline A would add ~1000+ lines to an already monolithic file and create permanent code duplication. (7) Creating a unified third pipeline would break both existing pipelines during migration. The concrete migration path: (a) Add /vitto-api proxy entry to frontend proxy config, (b) Update startWorkflow() to call VITTO_API_URL/module-generation/generate, (c) Adapt SSE event handlers for Pipeline B's event types (ModuleGenSSEEventType), (d) Move Pipeline A's unique features (module catalog reuse, splitIntoModules) into Pipeline B's DECOMPOSE phase. Early warning signal: if Pipeline B's SSE event format diverges significantly from what the frontend expects, the adapter layer could become complex.

📁 Files Involved

• libs/libs-ai/gograb-ai-lib/src/lib/services/workflow-state.service.ts
• apis/backend-ai-api/src/app/workflow/workflow.service.ts
• apis/backend-vitto-api/src/app/module-generation/module-generation.controller.ts
• apis/backend-vitto-api/src/app/module-generation/phases/module-gen-phase.executor.ts

🔗 Related

• Decision ID: dev_1771869715563_5uos6mg
• Session: 138
• Workspace: gspace1

Auto-generated by MCP Smart Consolidation