🏗️ Architecture: How should the native VSCode chat be architecturally brought...

Date: 2026-03-28
Time: 15:26:46 UTC
Session: gspace1-284.3
Agent: angular
Confidence: 93%
Status: ✅ Documented

📋 Decision Context

Question:

How should the native VSCode chat be architecturally brought to parity with the web vitto-chat?

Task: S284: Architecture for native VSCode chat parity with web vitto-chat (reattributed from S282)

🎯 Decision Made

Chosen:

5-phase enhancement plan: P0 (critical fixes), P1 (plugin system + markdown), P2 (rich rendering — tool renderers, generative UI, activity cards), P3 (multi-session management), P4 (plugin completeness), P5 (polish). Two independent critical paths: visual parity (markdown-it → tool renderers → body parser → generative UI) and behavioral parity (plugin core → capabilities → all 15 applicable plugins). Key architecture: reuse @libs-ai/chat-plugin-core directly in Lit (zero Angular deps), Lit component registry for dynamic plugin UI, markdown-it + DOMPurify for secure rendering, V2 multi-session storage schema.

Options Considered:

1. Rebuild entire vitto-chat as Angular iframe (rejected: already tried, heavy, defeats native purpose)
2. Port plugins one-by-one with Angular-to-Lit wrappers (rejected: unnecessary since chat-plugin-core is already framework-agnostic)
3. Build Lit equivalents from scratch ignoring plugin system (rejected: duplicates 17 plugins worth of logic)
4. Reuse chat-plugin-core directly + build Lit component registry (chosen: highest leverage, zero duplication)

💭 Reasoning

Root cause of the parity gap: the native chat was built as a lightweight sidebar with a regex markdown parser, generic tool cards, single-session storage, and no plugin integration — despite chat-plugin-core already being framework-agnostic. Gap analysis revealed: 4/17 plugins partially supported, 11 completely missing, 2 N/A. Message rendering was the biggest quality gap: no syntax highlighting, no tool renderers (14 specialized vs 1 generic in web), no generative UI (7 block types), no activity cards (10+ types). The chat-plugin-core library uses ReactiveValue = () => T (not Angular Signal) and ComponentRef = unknown (not Angular Type), meaning ALL plugins can be instantiated directly in Lit without bridging. This is the highest-leverage architectural insight — it eliminates the need to rebuild the plugin system. Backend changes needed: event mapper was suppressing agent.iteration, task.stuck, and token counts in task.completed, giving users zero visibility into cost or stuck states.

📁 Files Involved

• docs/english/vitto/vitto-vscode-extension-native-chat-spec.md
• libs/libs-ai/chat-plugin-core/src/lib/interfaces/chat-plugin.interface.ts
• libs/libs-ai/chat-plugin-core/src/lib/types/plugin-capabilities.ts
• APIs/backend-vitto-api/src/app/engine/utils/agent-session-event-mapper.ts

🔗 Related

• Decision ID: dev_1774711606834_78o6bwt
• Session: 284
• Workspace: gspace1

Auto-generated by MCP Smart Consolidation