🏗️ Architecture: How should executive instruction endpoints be guarded to pre...

Date: 2026-03-12
Time: 18:11:33 UTC
Session: gspace1-209.3
Agent: backend
Confidence: 95%
Status: ✅ Documented

📋 Decision Context

Question:

How should executive instruction endpoints be guarded to prevent unauthorized access?

Task: Guard executive instruction endpoints

🎯 Decision Made

Chosen:

Add @Roles(SystemRoles.EXECUTIVE) to POST/PUT/DELETE executive/instructions endpoints. Keep GET as @Public() for read access. The hierarchy-aware RolesGuard ensures only level 90+ (executive, system) can mutate directives.

Options Considered:

1. Add @Roles(SystemRoles.EXECUTIVE) — correct, uses hierarchy
2. Add manual role check in service layer — wrong layer, duplicates guard logic
3. Add @Roles(SystemRoles.ADMIN) — too permissive, admins shouldn't write strategic directives

💭 Reasoning

The executive instruction endpoints (create, update, deactivate) had TODO comments acknowledging the need for role >= 90 enforcement but it was never implemented. Any authenticated user could create space-level directives that shape Vitto's behavior — a critical governance gap. The Vitto controller already uses @UseGuards(JwtAuthGuard, RolesGuard) at class level and imports SystemRoles from @libs-api/auth-core, so adding the decorator was a one-line fix per endpoint. Read access (GET) remains open because all authenticated users should be able to see what directives govern their space.

📁 Files Involved

• APIs/backend-vitto-api/src/app/engine/vitto.controller.ts
• APIs/backend-vitto-api/src/app/engine/executive-instructions.service.ts

🔗 Related

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

Auto-generated by MCP Smart Consolidation