La misión

Convierte tu agenda en un sistema para un pequeño equipo: registro y login con contraseña hasheada, recuperación por correo simulada, y tres roles —propietario, editor, solo lectura— con una matriz de permisos que TÚ defines antes de pedir una línea. Cada contacto pasa a tener dueño y visibilidad por equipo. El objetivo oculto del proyecto: que la auditoría final encuentre cero puertas traseras. Si «funciona» pero cualquiera puede editar al otro, falló.

La ruta, seis tiempos

Ruta del proyecto 3

ESPECIFICACION.md abre con la tabla: operación × rol, sin casillas en blanco. El «propietario» puede invitar y eliminar equipo; el «editor» crear y editar del equipo; «solo lectura» ver lo compartido. Toda regla «excepto cuando…» se escribe explícita o se convierte en bug futuro.
usuarios, sesiones/tokens, pertenencia a equipo con rol, contacto con equipo_id. La IA propone y tú revisas relaciones y claves (M7-OA03): ¿qué pasa con los contactos si se va el único propietario? La respuesta va en la especificación.
El prompt del registro/login con la lista de no-negociables: hash con librería estándar, nada de contraseñas en log, límite de intentos, sesión que expira. Cada candado es un criterio de aceptación medible, no un deseo.
La trampa clásica: el menú del frontend oculta los botones y parece que funciona. La revisión verifica lo que el menú no puede hacer por ti: que cada endpoint cheque rol Y propiedad, no solo «está logueado».
Token caducado en la laptop compartida, usuario 2 llamando directo al endpoint de borrado del 1, contraseña «123456» en el registro. PRUEBAS.md documenta las tres puertas: si alguna se abrió, el hallazgo vale oro.
Variables de entorno para clave de sesión y credenciales de base, HTTPS encendido (la contraseña por http en claro es el detalle que demolería todo el módulo 10), URL pública y repo.

El prompt de autenticación (con los no-negociables)

La línea 6 y la prueba de propiedad cruzada: donde mueren los sistemas a medias

Capa nueva del proyecto 3: autenticacion y roles. Stack del documento maestro.\n\nNo negociables (cada uno es un criterio de aceptacion VERIFICABLE):\n1. contrasenas con hash de libreria estandar (bcrypt/argon segun stack), nunca en claro\n2. la contrasena nunca aparece en logs ni en mensajes de error, ni en la respuesta del API\n3. limite de intentos de login (5 por correo/hora) con espera creciente\n4. sesion con token de duracion limitada; el cliente guarda el token segun la practica\n   correcta del stack y lo manda en cada peticion\n5. recuperacion: token de un solo uso con expiracion corta (simulable por correo local)\n6. TODOS los endpoints protegidos chequean: token valido + rol adecuado + propiedad del\n   recurso. El frontend que oculta botones es UX, no defensa: la barrera vive aca.\n\nMatriz de permisos (definida por mi en ESPECIFICACION.md, pegarla completa aqui):\n[pega tu tabla operacion x rol literal]\n\nPruebas por endpoint: sin token (401), rol equivocado (403), propiedad cruzada\n(el editor del equipo A toca un contacto del equipo B -> 403), token caducado.\n\nImplementa, corre todo, muestra diff y salida. No toques la logica de contactos de\nla capa 2 sin mostrarme el diff de lo que cambia.

Qué entrega este proyecto

Si tu auditoría de las tres puertas encuentra cero errores en el primer intento, sospecha: no es que esté perfecto, es que la prueba fue suave. Los mejores HALLAZGOS.md de este proyecto nacen de la puerta que sí se abrió.
Entregable	Barra alta de este proyecto
ESPECIFICACION.md	la matriz operación × rol sin casillas en blanco y el caso del propietario que se va
HALLAZGOS.md	el endpoint que dejaba pasar al usuario equivocado, el login que logueaba la contraseña
PRUEBAS.md	las tres puertas auditadas + propiedad cruzada por endpoint crítico
App publicada	dos cuentas reales de prueba editando cada una lo suyo, nada más

Prueba

Tu sistema: el menú muestra el botón «eliminar» solo al propietario, y los demás no lo ven. ¿Es suficiente para cumplir la matriz?

Almacena la contraseña con hash (no en claro) y ya: con eso la autenticación del proyecto está bien protegida.

Empieza por el punto que la IA no puede escribir por ti: la matriz operación × rol completa, en ESPECIFICACION.md. Luego el prompt de capa con los seis no-negociables. Cierra con la auditoría de las tres puertas Y la propiedad cruzada documentadas —si la primera prueba te deja limpio, prueba más sucio.

Pista

Un sistema de permisos es una decisión de negocio escrita dos veces: una en la especificación, otra en cada endpoint.