🏗️ Architecture: How should local disk write of generated code be controlled ...

Date: 2026-03-11
Time: 19:38:11 UTC
Session: gspace1-204.14
Agent: backend
Confidence: 95%
Status: ✅ Documented

📋 Decision Context

Question:

How should local disk write of generated code be controlled — env var (SAVE_GENERATED_LOCALLY) or per-user preference in MongoDB?

Task: S204.18: Replace SAVE_GENERATED_LOCALLY with user preference

🎯 Decision Made

Chosen:

Replace SAVE_GENERATED_LOCALLY env var with GenerationPreferences sub-schema on UserPreferences (MongoDB). Local write gated by: (1) user role is admin/developer/executive, (2) user.generation.localFallbackEnabled === true, (3) GitLab commit failed. Vitto fetches preferences via BackendApiClientService.getGenerationPreferences().

Options Considered:

1. Keep SAVE_GENERATED_LOCALLY env var but add role check
2. Per-user preference in UserPreferences MongoDB collection (chosen)
3. Per-space setting on the Space document
4. Feature flag via LaunchDarkly or similar

💭 Reasoning

Env vars are server-wide — they can't distinguish between a GoGrab developer who wants local fallback and a SaaS customer who should never touch the filesystem. The user preference approach gives per-user control, uses the existing UserPreferences collection (already has privacy, chat, AI assistant prefs), and follows the established BackendApiClientService inter-service communication pattern. The 3-gate check (role + preference + GitLab failure) ensures local write is a fallback, not a parallel write — preventing monorepo pollution. Default is OFF, so no behavior change for existing users.

📁 Files Involved

• libs/libs-api/backend-core/src/lib/schemas/user-preferences.schema.ts
• APIs/backend-vitto-api/src/app/connectivity/backend-api-client.service.ts
• APIs/backend-vitto-api/src/app/module-generation/phases/module-gen-phase.executor.ts

🔗 Related

• Decision ID: dev_1773257891604_tksqgmf
• Session: 204
• Workspace: gspace1

Auto-generated by MCP Smart Consolidation