Roles y permisos

---
name: roles-y-permisos
description: quién puede ver qué, y quién puede borrarlo.
---

# Roles y permisos

Instrucciones para el agente que está construyendo esta app. Sigue esta skill cuando
agregues espacios de trabajo, invitaciones, roles o cualquier verificación de acceso.

## Cuándo usar esta skill

Actívala en cuanto se cumpla cualquiera de estas condiciones:

- Más de una persona comparte el mismo contenido o proyecto.
- Hay algo que un miembro del equipo no debería ver: facturación, datos de clientes,
  exportaciones.
- Vendes por asiento y necesitas invitar, quitar y contar miembros.
- Existe una vista de administrador distinta de la vista normal.

Esta capa separa "tengo cuenta" de "puedo hacer esto". Es lo que casi siempre falta en un
rebuild de fin de semana: el demo funciona con un usuario y filtra datos ajenos en
cuanto entra el segundo.

## Cómo construirla

Usa este stack salvo que el proyecto ya tenga otro decidido: **Postgres** con
organizaciones y membresías, verificación centralizada en el servidor, sin lógica de
permisos en el cliente.

1. Agrega organizaciones y membresías: cada recurso cuelga de una organización, nunca
   directamente de un usuario.
2. Empieza con tres roles fijos (`owner`, `member`, `viewer`). Los permisos por recurso
   llegan cuando alguien los pida de verdad, no antes.
3. Escribe una sola función que responda `puedeHacer(usuario, accion, recurso)` y
   llámala en cada endpoint. Una función, no quince `if` sueltos repartidos por el
   código.
4. Filtra siempre por organización en la consulta, no después de traer las filas.
5. Invitaciones por token con correo, expiración y aceptación explícita.
6. Registra quién cambió roles y cuándo: es el primer dato que te van a pedir cuando
   algo salga mal.

## En qué te vas a trabar

- **Ocultar un botón no es un permiso.** Si el endpoint no verifica, el permiso no
  existe, sin importar qué tan bien escondido esté en la UI.
- **El caso difícil es el último dueño:** no dejes que se elimine a sí mismo y deje la
  organización huérfana sin nadie que pueda administrarla.
- **Los permisos por campo (ver el precio pero no el margen) multiplican la
  complejidad.** Evítalos hasta tener clientes que de verdad los pidan.

## Criterio de terminado

No declares esto listo hasta que un usuario de una organización no pueda ver ni un solo
registro de otra, la eliminación del último dueño esté bloqueada, y `puedeHacer` sea el
único lugar donde vive la lógica de permisos.