🏗️ Architecture: How should VittoConfigService and frontend components map th...

Date: 2026-03-12
Time: 18:11:51 UTC
Session: gspace1-209.5
Agent: angular
Confidence: 93%
Status: ✅ Documented

📋 Decision Context

Question:

How should VittoConfigService and frontend components map the 'admin' role — developer tier or platform_builder tier?

Task: Fix role-to-tier mapping across backend and frontend

🎯 Decision Made

Chosen:

Demote 'admin' from developer tier to platform_builder tier. Developer tier = executive + developer + system. Platform_builder tier = admin + manager. End_user tier = user + viewer + editor + guest.

Options Considered:

1. Keep admin in developer tier (wrong — gives ops team engine-level control)
2. Move admin to platform_builder tier (correct — matches responsibility boundary)
3. Create a new 'operator' tier between developer and platform_builder (over-engineering)

💭 Reasoning

The previous mapping gave admins (level 60) the same config access as developers (level 80) — they could modify execution mode, tool preferences, codebase indexing, and budget settings. This conflated operational management with engineering control. With the corrected hierarchy, admins are platform operators who manage day-to-day operations, while developers and executives need full technical control. The platform_builder tier gives admins workspace events and autonomy preferences without exposing engine-level settings. The frontend VittoSettingsComponent was also wrong — it mapped 'editor' to developer tier, which gave content editors full developer settings access.

📁 Files Involved

• APIs/backend-vitto-api/src/app/engine/vitto-config.service.ts
• libs/libs-ai/vitto-hub/src/lib/components/vitto-settings/vitto-settings.component.ts

🔗 Related

• Decision ID: dev_1773339111511_l40lg1a
• Session: 209
• Workspace: gspace1

Auto-generated by MCP Smart Consolidation