Architecture: Session 184: How to make plugin/welcome system open/closed —...

Documentation for Sessions

🏗️ Architecture: Session 184: How to make plugin/welcome system open/closed —...

Date: 2026-03-06
Time: 16:34:05 UTC
Session: gspace1-184.2
Agent: angular
Confidence: 92%
Status: ✅ Documented


📋 Decision Context

Question:

Session 184: How to make plugin/welcome system open/closed — remove hardcoded maps, unify context types?

Task: Not specified


🎯 Decision Made

Chosen:

WelcomeContentRegistry (signal-based, providedIn root) as separate service, NOT on ChatPlugin. Canonical context types split into RouteContext (where user is) + CapabilityContext (what AI can do) in core-models. One-way bridge from AIPanelCoreStateService to VittoChatContextService. Single-pass migration with no fallback dual code paths.

Options Considered:

  1. Put welcome on ChatPlugin interface (original plan)
  2. Separate WelcomeContentRegistry service (chosen)
  3. Angular DI multi-providers for welcome content

💭 Reasoning

Original plan proposed putting welcome content on ChatPlugin interface, but most contexts (page-builder, dashboard, analytics) don't have ChatPlugins — would force creating 10+ empty plugins just to carry welcome data. Separate registry decouples welcome content from chat behavior. Context types stay semantically split (RouteContext vs CapabilityContext) because they represent different concepts — merging them into one type hides the mapping instead of eliminating it. The S182 bug (map keys using wrong type) becomes a compile error with explicit typed mapping. AIPanelCoreState->VittoChatContext bridge fills the parallel state gap. Studio uses callback pattern (registerWelcome) to avoid build dependency on vitto-chat.


📁 Files Involved


🔗 Related


Auto-generated by MCP Smart Consolidation