Architecture: How should sub-Vitto SSE events be scoped to avoid polluting...

Documentation for Sessions

🏗️ Architecture: How should sub-Vitto SSE events be scoped to avoid polluting...

Date: 2026-03-18
Time: 16:42:07 UTC
Session: gspace1-234.5
Agent: backend
Confidence: 93%
Status: ✅ Documented

📋 Decision Context

Question:

How should sub-Vitto SSE events be scoped to avoid polluting the parent event stream?

Task: S234.2: Sub-Vitto Engine - SSE event scoping

🎯 Decision Made

Chosen:

Created SubVittoSSEProxy — a lightweight wrapper that subscribes to a child Subject, maps event types via a static TYPE_MAP (agent.iteration→subvitto.progress, tool.called→subvitto.tool, etc.), injects subTaskId/parentTaskId metadata, and forwards to the parent Subject. Disposed per-task in finally blocks.

Options Considered:

  1. Modify AgentLoopService to accept event type prefix
  2. Post-filter events on frontend by taskId
  3. SubVittoSSEProxy wrapper (chosen)
  4. Separate SSE endpoints per sub-Vitto

💭 Reasoning

Without scoping, sub-Vitto events (agent.iteration, tool.called) are indistinguishable from the parent's events in the SSE stream. The proxy pattern was chosen over: (1) modifying AgentLoopService to accept a type prefix (invasive, breaks all callers), (2) post-filtering on the frontend (wasteful, requires all events to be sent), (3) using separate SSE endpoints per sub-Vitto (complex, requires dynamic endpoint creation). The proxy is ~55 lines, has zero NestJS dependencies, and follows the same delegation pattern as WhatsAppProgressEmitter. The TYPE_MAP is extensible — adding new event mappings is a one-line change.

📁 Files Involved

🔗 Related

Auto-generated by MCP Smart Consolidation