Architecture: How should the Chrome extension panel be upgraded from proto...

Documentation for Sessions

🏗️ Architecture: How should the Chrome extension panel be upgraded from proto...

Date: 2026-02-10
Time: 18:40:43 UTC
Session: gspace1-103.3
Agent: storage
Confidence: 88%
Status: ✅ Documented


📋 Decision Context

Question:

How should the Chrome extension panel be upgraded from prototype to production tier-aware AI?

Task: Session 103: Upgrade Chrome extension from prototype to production tier-aware AI panel


🎯 Decision Made

Chosen:

4-phase approach: (1) Runtime domain blocklist in inject.js for API subdomains, (2) Pass userRole+hostApp from chrome.storage to panel iframe URL params, extend AuthPayload with role/userType, (3) New ExtensionPanelComponent wrapping production AiPanelComponent from @libs-ai/vitto-hub with TenantContext per user tier, (4) Role-based popup section visibility. Prototype panel kept at /panel-legacy.

Options Considered:

  1. Modify AiPanelComponent to handle extension context internally
  2. Create entirely new extension-specific panel from scratch
  3. Wrapper component that delegates to production AiPanelComponent with extension-specific init

💭 Reasoning

The extension was loading a ~200-line prototype PanelComponent while a 2880-line production AiPanelComponent existed in vitto-hub with tier-awareness, multi-mode, streaming, and drag-drop. Rather than modifying the lib, we created a thin wrapper (ExtensionPanelComponent) that reads URL params from the extension, maps role→UserType→TenantContext, and passes computed config to the production panel. This reuses 100% of existing production code. Domain filtering uses runtime check (not manifest narrowing) because broad manifest patterns are needed for auth sync. UserType defined locally in frontend to avoid importing backend-core deps.


📁 Files Involved


🔗 Related


Auto-generated by MCP Smart Consolidation