Architecture: How should the gograb-ai /dashboard route be structured?

Documentation for Sessions

🏗️ Architecture: How should the gograb-ai /dashboard route be structured?

Date: 2026-02-11
Time: 17:59:51 UTC
Session: gspace1-105.21
Agent: angular
Confidence: 90%
Status: ✅ Documented

📋 Decision Context

Question:

How should the gograb-ai /dashboard route be structured?

Task: Session 105.3: Dashboard rewrite as intelligent hub

🎯 Decision Made

Chosen:

Rewrite as an intelligent hub/launchpad — not a control center. Role-aware, real data only, no mock data.

Options Considered:

Full control center with mock data fallback
Intelligent hub with real data and offline state
Remove dashboard entirely, redirect to /panel

💭 Reasoning

The old dashboard had extensive mock data, stub buttons, and tried to be a control center. The user explicitly requested an 'intelligent guide/orchestrator' that shows real data, adapts to user role, and provides meaningful navigation to the actual tools (/panel, /observatory, /vitto) and cross-app deep links. Mock data was stripped from McpStatusService — when backend is unreachable, the UI shows 'Offline' with a retry button instead of fake numbers.

📁 Files Involved

apps/gograb-ai/src/app/pages/dashboard/dashboard.component.ts
apps/gograb-ai/src/app/core/services/mcp-status.service.ts

🔗 Related

Decision ID: dev_1770832791572_9m7k36q
Session: 105
Workspace: gspace1

Auto-generated by MCP Smart Consolidation