🏗️ Architecture: How should Vitto Studio access generated code — local disk o...

Date: 2026-03-10
Time: 18:57:44 UTC
Session: gspace1-199.4
Agent: backend
Confidence: 93%
Status: ✅ Documented

📋 Decision Context

Question:

How should Vitto Studio access generated code — local disk or GitLab repos?

Task: S199: GitLab-backed Studio file operations

🎯 Decision Made

Chosen:

GitLab-backed file operations via new StudioRepoController on backend-ai-api. Studio reads/writes from GitLab repos through REST endpoints. Local disk preserved as future option for power users.

Options Considered:

1. Keep disk-only (blocks cloud users)
2. R2 as primary storage (adds complexity, GitLab already exists)
3. GitLab-backed with disk fallback (chosen — leverages existing infrastructure)
4. Direct GitLab API from frontend (security risk, CORS issues)

💭 Reasoning

ROOT CAUSE: VfsSyncService loaded modules via listModulesOnDisk() which scanned the local filesystem. This only works for developers running the monorepo locally. Cloud users (the primary audience) never have local disk — GitLab is their only storage. The fix creates a StudioRepoController that proxies to backend-api's GitLabProviderService via HTTP. This gives Studio the same file operations (list, read, write, commit) but backed by GitLab repos instead of local disk. The controller lives on backend-ai-api (port 3001) because Studio already uses AI_API_URL for module file operations. Frontend StudioApiService gets parallel methods (listModulesFromRepo, getFileFromRepo, commitFileToRepo) alongside existing disk-based methods for future local dev mode.

📁 Files Involved

• APIs/backend-ai-api/src/app/module-files/studio-repo.controller.ts
• APIs/backend-ai-api/src/app/module-files/module-files.module.ts
• libs/libs-structural/vitto-studio/src/lib/services/studio-api.service.ts

🔗 Related

• Decision ID: dev_1773169064050_mm8vq2i
• Session: 199
• Workspace: gspace1

Auto-generated by MCP Smart Consolidation