Architecture: How should Vitto's new Jarvis capabilities (reasoning, backg...

Documentation for Sessions

🏗️ Architecture: How should Vitto's new Jarvis capabilities (reasoning, backg...

Date: 2026-03-19
Time: 14:20:29 UTC
Session: gspace1-238.6
Agent: angular
Confidence: 93%
Status: ✅ Documented

📋 Decision Context

Question:

How should Vitto's new Jarvis capabilities (reasoning, background tasks, skill learning, autonomy gating, etc.) be rendered in the chat UI?

Task: Not specified

🎯 Decision Made

Chosen:

Activity Card System — extend the streaming service with an activity_card event type and an ActivityCardHostComponent that dynamically resolves card components from a registry. 8 card types self-register at import time. NOT via the ChatPlugin interface (which lacks SSE-to-card dispatch).

Options Considered:

  1. Extend ChatPlugin interface with SSE event handlers
  2. Create 8 separate plugins (one per card type)
  3. Build outside the plugin system — extend streaming service + ActivityCardHostComponent

💭 Reasoning

Root cause analysis: The existing ChatPlugin interface supports tabs, slashCommands, quickActions, and outputComponents — none of which map to dynamically rendering inline cards from SSE events. The GenerationPlugin was initially considered as a pattern but it does NOT do SSE-to-card dispatch either. The correct layer is the streaming service (which already handles tool result rendering) + a dynamic card host using NgComponentOutlet. This avoids plugin proliferation (one host, many card types via registry) and integrates naturally with the existing message stream. Alternative considered: extending ChatPlugin with sseEventHandlers — rejected because it would add complexity to an interface that 12+ plugins already implement, and SSE handling is fundamentally a streaming concern, not a plugin concern.

📁 Files Involved

🔗 Related

Auto-generated by MCP Smart Consolidation