🏗️ Architecture: How to make vittoApiUrl a first-class citizen in the central...

Date: 2026-03-31
Time: 19:05:32 UTC
Session: gspace1-290.25
Agent: architecture
Confidence: 95%
Status: ✅ Documented

📋 Decision Context

Question:

How to make vittoApiUrl a first-class citizen in the centralized environment config system alongside the other 3 API URLs?

Task: Vitto prod/dev/staging separation

🎯 Decision Made

Chosen:

Add vittoApiUrl to EnvironmentConfig interface, all 5 ENVIRONMENT_PRESETS, API_CONFIG composite token, and ApiConfiguration interface — making Vitto follow the exact same resolution path as backend/ai/docs APIs

Options Considered:

1. Add vittoApiUrl to centralized EnvironmentConfig + presets (chosen)
2. Keep Vitto on separate smart-factory path, just fix individual apps
3. Create a new VittoEnvironmentConfig parallel system

💭 Reasoning

Root cause: vittoApiUrl was added incrementally in Session 139 via inject(VITTO_API_URL, { optional: true }) with a smart factory fallback. The other 3 APIs (backend, ai, docs) are in EnvironmentConfig interface and all ENVIRONMENT_PRESETS. This means: (a) detectEnvironment() returns configs without Vitto, (b) API_CONFIG composite token omits Vitto, (c) apps handle Vitto inconsistently — gograb-admin/dev use presets, gograb-ai hardcodes strings, space-admin is legacy. Option 1 unifies all 4 APIs on one path. Option 2 is a band-aid that preserves fragmentation. Option 3 is over-engineering. Future risk: if a 5th API is added, it should follow this same pattern. The staging URLs were also stale (pointing to .up.railway.app instead of custom staging-*.gograb.space domains from the staging environment spec).

📁 Files Involved

• libs/libs-foundational/api-config/src/lib/environment-presets.ts
• libs/libs-foundational/api-config/src/lib/api-tokens.ts

🔗 Related

• Decision ID: dev_1774983932233_0bkg358
• Session: 290
• Workspace: gspace1

Auto-generated by MCP Smart Consolidation