Architecture: Session 184.2: What is the correct architecture for the AI p...

Documentation for Sessions

🏗️ Architecture: Session 184.2: What is the correct architecture for the AI p...

Date: 2026-03-06
Time: 18:51:16 UTC
Session: gspace1-184.4
Agent: storage
Confidence: 92%
Status: ✅ Documented


📋 Decision Context

Question:

Session 184.2: What is the correct architecture for the AI panel across all platforms (web apps, desktop, mobile, chrome extension)?

Task: Fix AI panel architecture across all platforms


🎯 Decision Made

Chosen:

Hybrid: Native ai-panel-tabs for all web apps (gograb-space, admin, dev, ai) with WebSocket real-time sync. Chrome extension keeps iframe+bridge for external sites only. Mobile/desktop already native (same app). Fix ai-panel-core module boundaries by making vitto-chat buildable. Add auth-aware panel state (sleeping/awake). Fix extension header (profile, close).

Options Considered:

  1. Keep iframe approach everywhere with bridge auth
  2. Native panels everywhere with WebSocket sync (chosen)
  3. Remove panel from host apps entirely, only use extension

💭 Reasoning

Root cause of all auth/login bugs: the guard treated embedded iframes like native apps, redirecting to /welcome (desktop deep-link flow). This happened because host apps relied on Chrome extension iframe injection instead of rendering panels natively. The iframe approach added unnecessary complexity: bridge auth, postMessage timing, cross-origin state sync, guard heuristics for embedded vs desktop vs mobile. Native rendering eliminates this entire class of bugs. Real-time sync across origins solved at data layer via existing WebSocket /chat gateway on backend-ai-api, not at DOM layer via same-origin localStorage hack. Drag-and-drop works natively (same DOM) and via bridge (for extension). Module boundary violation: ai-panel-core (buildable) imports from vitto-chat (non-buildable) — fix by making vitto-chat buildable.


📁 Files Involved


🔗 Related


Auto-generated by MCP Smart Consolidation