Architecture: S185: What is the correct architectural vision for Vitto Stu...

Documentation for Sessions

🏗️ Architecture: S185: What is the correct architectural vision for Vitto Stu...

Date: 2026-03-07
Time: 16:11:37 UTC
Session: gspace1-187.188
Agent: angular
Confidence: 97%
Status: ✅ Documented

📋 Decision Context

Question:

S185: What is the correct architectural vision for Vitto Studio — code editor or visual platform builder?

Task: S185→S186: Define Studio architectural vision

🎯 Decision Made

Chosen:

Visual platform builder with AI-first editing. Code view is secondary. The primary UX is: (1) Visual component rendering with click-to-select, (2) Vitto chat is context-aware of what user is looking at/clicking, (3) All changes via natural language or visual drag/drop, (4) Generated modules use existing GoGrab widgets/components/patterns (DRY), (5) Use @libs-ui/dock-layout for panel management. Non-developers are the primary users.

Options Considered:

  1. Code-editor-first approach (current, developer-focused)
  2. Visual builder with AI chat as primary editing interface (chosen)
  3. Hybrid with equal weight on both (confusing UX for non-devs)

💭 Reasoning

S185 proved the pipeline works: entity→CRUD, 6-phase module generation, files on disk, Monaco editor. But the CEO feedback is clear: showing raw TypeScript files in a code editor serves developers, not the target audience (non-technical platform builders). The real value is in rendering the generated modules visually — showing the actual pages, forms, lists — and letting users edit them by clicking + chatting with Vitto. The code is an implementation detail that should be hidden by default. GoGrab already has a rich component library (ux-*, widgets, page renderers) that should be composed visually, not written manually.

📁 Files Involved

🔗 Related

Auto-generated by MCP Smart Consolidation