C6 fullstack

C6 — Reto Tecnico: Desarrollador FullStack#

Cargo: Desarrollador FullStack Tipo de reto: Desarrollo de producto Stack: Next.js 14 + NestJS (o similar) + Prisma + PostgreSQL + TailwindCSS Producto: TaskFlow — App Kanban colaborativa con pagos Metodologia de evaluacion: Ver 00-metodologia-evaluacion.md

1. Vision del Producto#

Producto: TaskFlow — una aplicacion Kanban donde equipos crean tableros, organizan tarjetas con drag-and-drop, y desbloquean funcionalidad premium con pagos via Stripe.

Problema que resuelve: Los equipos necesitan una herramienta visual para organizar tareas y ver el progreso en tiempo real.

Por que este reto para FullStack: TaskFlow requiere construir ambas capas — la API completa (auth, CRUD, pagos, websockets) y la interfaz completa (tableros, drag-and-drop, responsive, UX profesional). No se puede aprobar haciendo solo backend o solo frontend.

1.1 Roles del sistema#

2. Historias de Usuario — Backlog Priorizado#

H01 — Registro de usuario#

Prioridad: Critica | Nivel minimo: N1 | Estimacion: 2 pts

Como visitante, quiero crear una cuenta para poder usar la app.

Criterios de aceptacion:

• AC-01: Registro con nombre, email (unico, validado como email), y contrasena (minimo 8 chars, al menos 1 numero)
• AC-02: La contrasena se almacena hasheada con bcrypt (cost 10+). Nunca en texto plano
• AC-03: Al registrar exitosamente, inicia sesion automaticamente y redirige al dashboard
• AC-04: Si el email ya existe, mostrar "Este email ya esta registrado" (no revelar si es el email o la contrasena incorrecta en login)
• AC-05: Campo email es case-insensitive: "User@Mail.com" = "user@mail.com"

Definition of Done: Test de registro exitoso, registro con email duplicado, validacion de contrasena debil.

H02 — Login y sesion#

Prioridad: Critica | Nivel minimo: N1 | Estimacion: 2 pts

Como usuario registrado, quiero iniciar sesion para acceder a mis tableros desde cualquier dispositivo.

Criterios de aceptacion:

• AC-01: Login con email + contrasena. Devuelve JWT o cookie de sesion segura (httpOnly, secure, sameSite)
• AC-02: Si las credenciales son incorrectas, responde "Credenciales invalidas" (no diferenciar si es email o password)
• AC-03: El token/sesion expira a las 24 horas. Hay mecanismo de refresh
• AC-04: Logout destruye la sesion/invalida el token del lado del servidor
• AC-05: Las rutas protegidas redirigen a /login si no hay sesion valida

Definition of Done: Test de login exitoso, login fallido, y acceso a ruta protegida sin token.

H03 — CRUD de tableros#

Prioridad: Critica | Nivel minimo: N1 | Estimacion: 3 pts

Como usuario autenticado, quiero crear, ver, editar y eliminar tableros para organizar mis proyectos.

Criterios de aceptacion:

• AC-01: Crear tablero con nombre (obligatorio, max 100 chars) y descripcion (opcional, max 500 chars)
• AC-02: El creador es automaticamente admin del tablero
• AC-03: Listar tableros muestra solo los tableros donde el usuario es admin o miembro
• AC-04: Editar tablero: solo el admin puede cambiar nombre, descripcion y configuracion
• AC-05: Eliminar tablero: solo el admin. Pide confirmacion con el nombre del tablero (escribirlo para confirmar)
• AC-06: Eliminar tablero hace soft-delete (campo deletedAt). Los datos persisten 30 dias

Restriccion de plan:

• Usuario Free: maximo 3 tableros activos. Al intentar crear el cuarto, mostrar mensaje "Actualiza a Premium para tableros ilimitados" con CTA al flujo de pago
• Usuario Premium: sin limite

Definition of Done: Tests de CRUD. Test que valida el limite de 3 tableros para Free.

H04 — Columnas y tarjetas#

Prioridad: Critica | Nivel minimo: N1 | Estimacion: 3 pts

Como admin de un tablero, quiero crear columnas y tarjetas para modelar mi flujo de trabajo.

Criterios de aceptacion:

• AC-01: Cada tablero tiene columnas ordenadas. Columnas por defecto al crear tablero: "Por hacer", "En progreso", "Hecho"
• AC-02: CRUD de columnas: crear (nombre obligatorio, max 50 chars), renombrar, eliminar, reordenar
• AC-03: Eliminar columna pregunta que hacer con las tarjetas: moverlas a otra columna o eliminarlas
• AC-04: CRUD de tarjetas: crear (titulo obligatorio), editar, eliminar
• AC-05: Una tarjeta tiene: titulo (max 200 chars), descripcion (markdown, max 5000 chars), color de etiqueta (opcional), fecha limite (opcional), asignado a (usuario miembro, opcional)
• AC-06: Las tarjetas tienen un campo position (integer) para mantener el orden dentro de la columna

Definition of Done: Puedo crear un tablero, agregar 3 columnas, crear 5 tarjetas y ver todo renderizado correctamente.

H05 — Drag and drop de tarjetas#

Prioridad: Alta | Nivel minimo: N2 | Estimacion: 5 pts

Como miembro de un tablero, quiero arrastrar tarjetas entre columnas y reordenarlas para actualizar el estado de mis tareas visualmente.

Criterios de aceptacion:

• AC-01: Drag and drop funcional entre columnas (cambiar de "Por hacer" a "En progreso")
• AC-02: Drag and drop para reordenar dentro de la misma columna
• AC-03: El cambio se persiste inmediatamente en la base de datos (no se pierde al refrescar)
• AC-04: Animacion fluida durante el drag (feedback visual: sombra, placeholder en destino)
• AC-05: Funciona en desktop (mouse) y mobile (touch events)
• AC-06: Si dos usuarios mueven la misma tarjeta simultaneamente, el ultimo gana (last-write-wins) y el otro recibe notificacion visual

Consideraciones tecnicas:

• Usar libreria probada: dnd-kit, @hello-pangea/dnd, o react-beautiful-dnd
• El campo position debe recalcularse eficientemente (recomendado: fractional indexing o reindexacion batch)
• El update de posicion debe ser una sola transaccion en DB (columna + posicion atomicamente)

Definition of Done: Test E2E que mueve una tarjeta de columna A a columna B y verifica persistencia.

H06 — Invitar usuarios a tableros#

Prioridad: Alta | Nivel minimo: N2 | Estimacion: 3 pts

Como admin de un tablero, quiero invitar a otros usuarios por email para que colaboren en mi tablero.

Criterios de aceptacion:

• AC-01: Buscar usuarios por email. Si existe, agregar como miembro del tablero
• AC-02: Si el email no esta registrado, enviar invitacion por email (o simular con log en consola para el reto)
• AC-03: El admin ve la lista de miembros con rol (admin/miembro)
• AC-04: El admin puede remover miembros. No puede removerse a si mismo (es admin)
• AC-05: Un miembro puede abandonar un tablero voluntariamente
• AC-06: Restriccion Free: maximo 5 miembros por tablero

Definition of Done: Test que invita usuario, verifica que aparece en la lista, verifica limite Free.

H07 — API REST documentada#

Prioridad: Alta | Nivel minimo: N2 | Estimacion: 3 pts

Como evaluador tecnico, quiero poder consultar la API sin usar la interfaz para verificar que los endpoints funcionan correctamente.

Criterios de aceptacion:

• AC-01: Todos los endpoints siguen convenciones REST (GET para listar/obtener, POST para crear, PATCH para editar, DELETE para eliminar)
• AC-02: Respuestas usan codigos HTTP correctos: 200, 201, 204, 400, 401, 403, 404, 409, 422, 500
• AC-03: Los errores devuelven JSON con estructura consistente: { error: string, message: string, statusCode: number }
• AC-04: Documentacion Swagger/OpenAPI accesible en /api/docs o Postman collection en el repo
• AC-05: Endpoints de listado soportan paginacion: ?page=1&limit=20 con respuesta { data: [], meta: { total, page, limit, pages } }
• AC-06: Los endpoints protegidos devuelven 401 sin token y 403 si el usuario no tiene permisos

Endpoints esperados:

POST   /auth/register
POST   /auth/login
POST   /auth/logout
POST   /auth/refresh

GET    /boards              (listar mis tableros)
POST   /boards              (crear tablero)
GET    /boards/:id          (detalle de tablero con columnas y tarjetas)
PATCH  /boards/:id          (editar tablero)
DELETE /boards/:id          (soft-delete tablero)

POST   /boards/:id/columns           (crear columna)
PATCH  /boards/:id/columns/:colId    (editar/reordenar columna)
DELETE /boards/:id/columns/:colId    (eliminar columna)

POST   /boards/:id/cards              (crear tarjeta)
PATCH  /boards/:id/cards/:cardId      (editar tarjeta)
DELETE /boards/:id/cards/:cardId      (eliminar tarjeta)
PATCH  /boards/:id/cards/:cardId/move (mover tarjeta entre columnas)

POST   /boards/:id/members            (invitar miembro)
DELETE /boards/:id/members/:userId    (remover miembro)

GET    /subscriptions/plans            (listar planes)
POST   /subscriptions/checkout         (iniciar pago)
POST   /subscriptions/webhook          (recibir evento de Stripe)

Definition of Done: Swagger accesible. Todos los endpoints responden con los codigos correctos.

H08 — Modelo de datos y migraciones#

Prioridad: Alta | Nivel minimo: N2 | Estimacion: 2 pts

Como desarrollador que toma el proyecto, quiero poder levantar la base de datos con un solo comando.

Criterios de aceptacion:

• AC-01: Schema definido en Prisma (o TypeORM) con migraciones versionadas en el repo
• AC-02: npx prisma migrate deploy (o equivalente) levanta toda la estructura sin errores
• AC-03: Script de seed que crea datos de prueba: 2 usuarios, 3 tableros, columnas y tarjetas de ejemplo
• AC-04: Indices en: email de usuario (unique), boardId en columnas y tarjetas, deletedAt para soft-delete queries

Modelo minimo esperado:

User: id, name, email (unique), password, plan (FREE/PREMIUM), createdAt, updatedAt
Board: id, name, description, ownerId (FK User), deletedAt, createdAt, updatedAt
BoardMember: id, boardId (FK), userId (FK), role (ADMIN/MEMBER), joinedAt
Column: id, boardId (FK), name, position, createdAt
Card: id, columnId (FK), title, description, color, dueDate, assigneeId (FK User nullable), position, createdAt, updatedAt
Subscription: id, userId (FK), stripeCustomerId, stripeSubscriptionId, plan, status, currentPeriodEnd

Definition of Done: git clone + npm install + npx prisma migrate deploy + npx prisma db seed = base de datos lista.

H09 — Integracion de pagos (Stripe)#

Prioridad: Alta | Nivel minimo: N3 | Estimacion: 5 pts

Como usuario Free, quiero pagar para desbloquear el plan Premium y tener tableros ilimitados.

Criterios de aceptacion:

• AC-01: Pagina de precios muestra los dos planes: Free (gratis, 3 tableros, 5 miembros) vs Premium ($9.99/mes, ilimitado)
• AC-02: Boton "Suscribirse a Premium" redirige a Stripe Checkout (modo test con claves pk_test_* / sk_test_*)
• AC-03: Al pagar exitosamente, Stripe llama al webhook POST /subscriptions/webhook
• AC-04: El webhook actualiza el campo plan del usuario de FREE a PREMIUM y registra la suscripcion
• AC-05: Si el pago falla o es cancelado, el usuario permanece en Free. Mostrar mensaje de error
• AC-06: El usuario Premium ve badge "Premium" en su perfil y no ve los limites de tableros
• AC-07: Cancelar suscripcion: el acceso Premium permanece hasta el fin del periodo pagado

Datos de prueba de Stripe:

• Tarjeta exitosa: 4242 4242 4242 4242, cualquier fecha futura, cualquier CVC
• Tarjeta que falla: 4000 0000 0000 0002
• Para Junior (N1): puede simular pagos con un endpoint mock que cambia el plan sin Stripe real

Seguridad critica:

• Las claves sk_test_* deben estar en .env, nunca en el codigo
• El webhook debe verificar la firma de Stripe (stripe-signature header)
• No confiar en datos del frontend para cambiar el plan — solo el webhook lo hace

Definition of Done: Flujo completo: usuario Free hace checkout, paga con tarjeta test, webhook procesa, usuario ahora es Premium, puede crear tablero 4.

H10 — Busqueda y filtros#

Prioridad: Media | Nivel minimo: N3 | Estimacion: 3 pts

Como miembro de un tablero con muchas tarjetas, quiero buscar y filtrar para encontrar lo que necesito rapidamente.

Criterios de aceptacion:

• AC-01: Buscar tarjetas por titulo (busqueda parcial, case-insensitive) dentro de un tablero
• AC-02: Filtrar tarjetas por: asignado a mi, por color de etiqueta, por fecha limite (vencidas, esta semana, sin fecha)
• AC-03: Los filtros son combinables (AND): "asignadas a mi" + "color rojo" + "vencidas"
• AC-04: La busqueda responde en menos de 200ms (para tableros de hasta 500 tarjetas)
• AC-05: Solo Premium: filtros avanzados. Free solo puede buscar por titulo

Definition of Done: Test que crea 50 tarjetas con diferentes atributos, aplica 3 filtros combinados, verifica resultados correctos.

H11 — Notificaciones en tiempo real#

Prioridad: Media | Nivel minimo: N3 | Estimacion: 5 pts

Como miembro de un tablero, quiero ver en tiempo real cuando alguien mueve una tarjeta o me la asigna.

Criterios de aceptacion:

• AC-01: WebSocket (Socket.io o WS nativo) conectado al entrar a un tablero
• AC-02: Cuando un usuario mueve una tarjeta, todos los miembros conectados ven el cambio sin refrescar
• AC-03: Cuando me asignan una tarjeta, recibo notificacion visual (toast/badge) en la interfaz
• AC-04: Indicador de "usuarios conectados" en el tablero (avatares o count)
• AC-05: Si la conexion WebSocket se pierde, reconectar automaticamente con backoff exponencial
• AC-06: Fallback: si WebSocket no esta disponible, polling cada 10 segundos

Definition of Done: Abrir 2 tabs del mismo tablero, mover tarjeta en tab 1, ver actualizacion en tab 2 en menos de 1 segundo.

H12 — Testing (ambas capas)#

Prioridad: Alta | Nivel minimo: N3 | Estimacion: 3 pts

Como equipo tecnico, queremos confianza de que el sistema funciona correctamente.

Criterios de aceptacion:

• AC-01: Tests unitarios backend: validacion de input, logica de permisos, calculo de limites por plan
• AC-02: Tests de integracion backend: endpoints de auth, CRUD de tableros, flujo de pagos
• AC-03: Tests de componentes frontend: al menos Board, Card, y DragDrop
• AC-04: Al menos 1 test E2E: flujo completo de registro, crear tablero, agregar y mover tarjeta
• AC-05: Coverage total > 60% (N3) o > 80% (N4)
• AC-06: Los tests corren con npm test sin configuracion adicional

Diferencia clave vs C2/C3: Al FullStack se le exige tests en ambas capas. No basta con tests solo de API o solo de componentes.

Definition of Done: npm test pasa. Coverage report generado. Tests cubren front y back.

H13 — CI/CD Pipeline (solo N4)#

Prioridad: Media | Nivel minimo: N4 | Estimacion: 3 pts

Criterios de aceptacion:

• AC-01: Pipeline en GitHub Actions: install → lint → test → build → deploy
• AC-02: El pipeline corre en push a main y en Pull Requests
• AC-03: Variables de entorno gestionadas con GitHub Secrets
• AC-04: Badge de estado en el README

Definition of Done: Push a main → pipeline verde → app actualizada.

H14 — Observabilidad (solo N4)#

Prioridad: Media | Nivel minimo: N4 | Estimacion: 3 pts

Criterios de aceptacion:

• AC-01: Logging estructurado (pino/winston). Formato JSON en produccion
• AC-02: Endpoint GET /health con status, version, uptime, DB connectivity
• AC-03: Error tracking (Sentry o similar): errores del frontend y backend se reportan
• AC-04: Metricas basicas: requests/s, latencia, tasa de errores

Definition of Done: Logs en JSON. Health endpoint funciona. Errores se reportan.

H15 — Documentacion de arquitectura (solo N4)#

Prioridad: Media | Nivel minimo: N4 | Estimacion: 2 pts

Criterios de aceptacion:

• AC-01: Diagrama de arquitectura C4 (o similar): contexto, containers, componentes
• AC-02: ADRs: al menos 3 decisiones documentadas (ORM, libreria D&D, estrategia de auth, pasarela de pagos)
• AC-03: README completo: setup, tests, deploy, env vars, diagrama
• AC-04: API documentada en Swagger accesible en /api/docs

Definition of Done: Un developer nuevo puede levantar, entender, y contribuir al proyecto leyendo la documentacion.

3. Diferencia clave: FullStack vs Backend (C2) vs Frontend (C3)#

La ventaja del FullStack es el tiempo adicional (2 horas mas). La desventaja es que se le evalua en todas las dimensiones y no puede ignorar ninguna capa.

4. Sprint Planning — Que completar segun tu nivel#

5. Timebox del Sprint#

Nota: FullStack tiene 8 horas para todos los niveles (vs 6h de Backend/Frontend), compensando la mayor superficie de evaluacion.

6. Entregables#

7. Stack sugerido (no obligatorio)#

Reto especifico para C6 — FullStack. Para la rubrica general y metodologia, ver 00-metodologia-evaluacion.md