Architecture: What technology and approach should be used for the GoGrab S...

Documentation for Sessions

🏗️ Architecture: What technology and approach should be used for the GoGrab S...

Date: 2026-02-24
Time: 22:41:07 UTC
Session: gspace1-138.3
Agent: backend
Confidence: 87%
Status: ✅ Documented

📋 Decision Context

Question:

What technology and approach should be used for the GoGrab Space native desktop app where Vitto lives?

Task: Session 141: GoGrab Space Native Desktop App - Where Vitto Lives

🎯 Decision Made

Chosen:

Tauri v2 shell wrapping existing Angular 20 gograb-ai frontend, with enhanced gograb-desktop-daemon as the local agent runtime. MongoDB (not SQLite) for task persistence via backend-vitto-api REST. Three-phase rollout: Phase 1 = Tauri tray/hotkey shell (Session 141), Phase 2 = enhanced daemon with screen capture + idle detection (next session), Phase 3 = cross-platform CI/CD.

Options Considered:

  1. Tauri v2 shell + enhanced daemon (chosen)
  2. Electron shell (larger binary, no Rust)
  3. Expand daemon only, no GUI (no system tray/hotkey)
  4. Chrome Extension only (web-first, limited OS integration)

💭 Reasoning

Tauri v2 wins on: 5-10MB binary vs 150MB Electron (critical for always-on tray app), 30-40MB RAM idle vs 250MB, uses native OS WebView (not bundled Chromium), cross-platform from single Rust codebase, official tray + global shortcut plugins. Existing gograb-ai is pure CSR Angular 20 (no SSR) so it works directly as Tauri webview. MongoDB keeps infrastructure unified — no new SQLite dependency. The gograb-desktop-daemon already has WebSocket relay + sentinel reconnect + OS notifications; Phase 2 adds screen capture, robotjs, idle detection.

📁 Files Involved

🔗 Related

Auto-generated by MCP Smart Consolidation