🏗️ Architecture: How should we resolve parallel role vocabularies (VittoUserT...

Date: 2026-03-19
Time: 21:56:41 UTC
Session: gspace1-241.3
Agent: documentation
Confidence: 95%
Status: ✅ Documented

📋 Decision Context

Question:

How should we resolve parallel role vocabularies (VittoUserType, VittoLayer, JWT roles vs PlatformRole) without breaking Mongo documents or active features?

Task: Create PlatformUser foundation fix spec for execution

🎯 Decision Made

Chosen:

Single source of truth: role-derivation.ts (PlatformRole + derivePermissions). Map legacy JWT roles where they enter the system, don't refactor schemas. Fix 7 foundation tasks first: slug resolution, password reset (currently lies), bulk invite email, self-registration behind flag, phone field, @Roles guard, L2→L4 comment fixes. Then implement notification specs in order.

Options Considered:

• No alternatives documented

💭 Reasoning

Both agents verified the same conclusion: the PlatformUser surface has 5 stubs (2 NotImplementedException, 1 silent no-op that returns success, 1 TODO that never sends, 1 TODO slug resolution). The two notification specs are well-designed but depend on this surface being truthful. The auth model (UnifiedAuthGuard + RolesGuard) is correct but PlatformUsersController lacks @Roles, leaving IDOR protection solely in service layer. Execution order: slug resolution first (dependency for password reset and self-reg), then password reset (highest user impact), then remaining tasks.

📁 Files Involved

• No files specified

🔗 Related

• Decision ID: dev_1773957401824_lslazs0
• Session: 241
• Workspace: gspace1

Auto-generated by MCP Smart Consolidation