Architecture: How should the vitto-chat plugin system be made framework-ag...

Documentation for Sessions

🏗️ Architecture: How should the vitto-chat plugin system be made framework-ag...

Date: 2026-03-23
Time: 17:01:39 UTC
Session: gspace1-258.2
Agent: angular
Confidence: 92%
Status: ✅ Documented

📋 Decision Context

Question:

How should the vitto-chat plugin system be made framework-agnostic for cross-platform reuse (VSCode extension, mobile, desktop)?

Task: S258: Build native vitto-chat into VSCode extension

🎯 Decision Made

Chosen:

Extract a new NX library @libs-ai/chat-plugin-core with zero Angular dependencies. Replace Signal with ReactiveValue (same call signature), Type with ComponentRef (opaque unknown), Angular services with provider interfaces. Plugin factories stay as pure function → POJO pattern. Platform capability negotiation system auto-filters plugins per surface.

Options Considered:

  1. Port plugin concept to Lit only (framework-specific, no reuse)
  2. Implement agent chat directly without plugin layer (simpler but misses reuse opportunity)
  3. Create framework-agnostic plugin core with capability negotiation (chosen — maximizes future leverage)

💭 Reasoning

17 plugins analyzed individually. Only 2 Angular concepts used across entire system: Signal (reactive getter) and Type (component reference). Both are replaceable with framework-agnostic equivalents at zero migration cost — Angular Signal IS a () => T callable, so ReactiveValue = () => T requires no wrapper. Three Angular barrel dependencies identified (embeddable-bridge, api-config, vitto-core) that would transitively pull Angular into the core — solved by extracting lightweight local types (PluginDropPayload, CHAT_MODEL_IDS, provider interfaces). Re-export shim in vitto-chat ensures zero breaking changes for existing consumers.

📁 Files Involved

🔗 Related

Auto-generated by MCP Smart Consolidation