S292-293: Vitto Capability System & Feature Enhancements

Progress Report (Non-Technical Summary)

Date: March 31, 2026
Sessions: S292 (design) + S293 (implementation)
Status: Phase 1 and Phase 2 complete. Phases 3-4 pending.

What Is This About?

GoGrab's AI assistant Vitto serves different types of users — executives, developers, admins, space builders, and end users. Until now, the platform had a simple "admin or not admin" check for deciding what users could see and do. This meant:

• A regular user could access developer tools by typing the URL directly
• Anyone with a login could manage the secret vault, generate code modules, or export audit logs
• The AI intelligence system had no access controls — any user could read or modify data belonging to other users
• Three important features (Memory Health, Knowledge Graph, Thought Trace) were built but never connected

This work fixes all of that by building a proper permission system that knows exactly what each type of user should be able to do.

Timeline of Progress

Step 1: Deep Audit (S292)

What we did: Analyzed every part of the platform to understand the current security state.

What we found:

• Backend AI API (intelligence): Critical — any logged-in user could read ALL decisions across ALL workspaces, and could inject rules into the intelligence system without any permission check
• Backend Vitto API (the AI brain): Serious gaps — the secret vault, skill management, code generation, and audit logs had zero permission checks
• Backend Main API (platform): Solid foundation but ~60 controllers lacked explicit permission markers
• Frontend: Everything was "admin or not" — 15 feature flags existed in the code but were never actually used by any component

Step 2: Design the Solution (S292)

What we decided: Build a "Capability Matrix" — a single list of everything the platform can do (~85 capabilities), who's allowed to do each thing, and whether those permissions can be customized.

Key design choices:

• Three types of endpoint protection: Public (no login needed), Authenticated (any logged-in user), and Capability-Gated (specific permission required)
• Three layers of customization: Platform defaults (set by the code) > Space overrides (set by space builders) > User overrides (set by executives)
• Some permissions are locked: Critical actions like editing Vitto's core values or impersonating users can never be granted through overrides — only executives can do these, period
• Self-enforcing: A startup check scans every endpoint when the server boots and warns if any endpoint is missing a permission marker

Step 3: Build the Foundation (S293 — Phase 1)

What we built:

Critical bugs found and fixed during this phase:

• Legacy user role names (like "manager" or "editor") were silently breaking the system — users with these roles were denied everything. Fixed by adding automatic role translation.
• The startup validator was reading the wrong metadata (Express wrappers instead of NestJS controllers) — rewritten to correctly scan all endpoints.

Step 4: Wire Missing Features + UI Migration (S293 — Phase 2)

What we built:

What Each Role Can Now Do

(This is a simplified view — the full matrix has 85 capabilities)

What's Still To Do (Phases 3-4)

Phase 3: Full Backend Migration + Intelligence Layering

• Add permission markers to the remaining ~60 backend-api controllers
• Add user/space filtering to the AI intelligence database queries (so users can only see their own data)
• Build the Intelligence visibility dashboard by role
• Build the Core Layer Management Dashboard for executives

Phase 4: New User-Facing Features

• Permission Editor: Executives can view and modify any user's capabilities through a visual interface
• Space Configuration: Space builders can customize what their space users can do
• Personal Preferences: Any user can customize their own Vitto experience (persona selection, notification preferences)
• Enable strict CI enforcement (builds fail if any endpoint is unprotected)

Impact Summary

Files Produced