El cuarto y último proyecto no mira al público: mira hacia dentro. Es la herramienta interna del equipo de Escena Viva, donde se coordina todo lo que ocurre antes de que se levante el telón. "Revisar sonido del Auditorio Ribera", "imprimir entradas del Festival", "confirmar rider del cuarteto", "montar gradas de la Sala Bóveda": tareas reales, con responsable, fecha de vencimiento y dependencias entre ellas.

La idea genuinamente nueva de este proyecto es la colaboración. Hasta ahora cada usuario era dueño de sus cosas: sus entradas, su pedido, sus artículos. Aquí varias personas trabajan sobre los mismos objetos al mismo tiempo, y eso rompe tres cosas de golpe: la autorización deja de resolverse con el rol global, dos ediciones simultáneas pueden pisarse, y hace falta un relato de "qué ha pasado" que nadie pueda alterar.

1. El requisito de negocio y decisiones de diseño
2. El modelo de datos
3. Autorización por pertenencia: más allá del RBAC
4. Ordenación manual sin renumerar la lista
5. Edición concurrente: bloqueo optimista y 412
6. El reto técnico: actividad y notificaciones
7. Tablero en vivo con Socket.IO
8. Vencimientos, filtros e informes
9. Exportación a CSV con streams
10. Pruebas de la política de permisos y qué queda fuera

• El trabajo se organiza en espacios: uno por sala (Teatro Almendra, Sala Bóveda, Auditorio Ribera) y uno por evento grande (evt-003).
• Cada espacio tiene miembros con un papel propio: observador, colaborador o responsable.
• Las tareas tienen estado, prioridad, vencimiento, persona asignada, etiquetas, subtareas y dependencias.
• El orden dentro de una columna lo decide una persona arrastrando, y ese orden es compartido.
• Todo cambio queda registrado en un historial de actividad por espacio.
• Los miembros reciben notificaciones agrupadas: nadie quiere 40 correos por una tarde de reorganización.
• El tablero se actualiza en vivo para quien lo tenga abierto.

Dependencias nuevas: ninguna obligatoria. sequelize, pg, bullmq, ioredis, zod, socket.io (del 12-01) y pino ya están. Solo si se opta por LexoRank en vez de posiciones fraccionarias conviene añadir una librería de rangos léxicos.

Estados: pendiente, en_curso, bloqueada, hecha. Pasar a en_curso exige que todas las dependencias estén hecha; si no, la tarea es bloqueada. Esa regla vive en el dominio:

En el M8 construiste exigirRol('organizador') y una política pura en src/autorizacion/politica.js, que resolvía preguntas como "¿puede este usuario crear eventos?". Aquí la pregunta es otra: "¿puede este usuario mover esta tarea de este espacio?". El rol global no contiene la respuesta porque depende de una relación que vive en la base de datos.

La solución no es meter consultas dentro de la política —dejaría de ser pura y probable sin base de datos—, sino cargar el contexto antes y decidir después.

Un middleware carga la pertenencia una vez por petición y la deja en peticion.pertenencia sin cortar nada —decide la política, no el middleware—. Otro, exigirPermiso(accion), llama a puede(...) y, si dice que no, elige el error: ACCESO_DENEGADO (403) si el usuario sí es miembro, y ESPACIO_NO_ENCONTRADO (404) si no lo es. Ese matiz importa: un 403 confirma que el espacio existe, y eso ya filtra información sobre la organización.

Y la parte importante: la comprobación se empuja a la consulta. En el M8 viste la referencia directa insegura: pedir /tareas/tar-8814 y recibirla porque nadie comprobó que fuera tuya. Con espacios, la tentación es cargar la tarea, mirar su espacioId y comparar. Funciona, pero es frágil —hay que acordarse en cada controlador— y hace dos viajes. Mejor: la pertenencia forma parte del WHERE.

Un repositorio que no tiene forma de devolver una tarea ajena es mucho más seguro que uno que la devuelve y confía en que alguien compruebe después: la seguridad que depende de recordar algo, tarde o temprano falla. Los listados siguen la misma regla, con WHERE t.espacio_id IN (SELECT espacio_id FROM miembros WHERE usuario_id = :usuarioId).

Marc arrastra "revisar sonido del Auditorio Ribera" desde el final de la columna a la segunda posición. Con posiciones enteras contiguas (1, 2, 3…), insertar en la 2 obliga a sumar uno a todas las siguientes: 300 filas actualizadas por arrastre y conflictos garantizados si dos personas arrastran a la vez.

Posiciones fraccionarias. La posición es un número real y la tarea se coloca en el punto medio entre sus vecinas:

El problema conocido de las fracciones es la precisión: double tiene 53 bits de mantisa, así que tras unas 50 inserciones en el mismo hueco dos posiciones se vuelven indistinguibles. Es raro pero real, y se resuelve detectándolo y recompactando esa lista —operación cara y muy poco frecuente—:

La alternativa: LexoRank. En vez de números, cadenas ordenables lexicográficamente (0|hzzzzz, 0|i00000…). Entre "a" y "b" siempre cabe "an", y entre "an" y "b" cabe "anv": nunca se agota el espacio, solo crece la longitud. Es lo que usa Jira; a cambio, la generación es más elaborada y el orden depende de la colación de la base de datos.

Para Escena Viva, con columnas de decenas de tareas, las fracciones son la decisión correcta: más simples, suficientes y con una salida clara si algún día dejan de serlo. Es una decisión pequeña y muy instructiva porque muestra el patrón completo: elige lo simple, conoce su límite, ten preparado el plan B.

Lucía y Marc abren la misma tarea. Lucía cambia la prioridad a alta; Marc, dos segundos después, cambia el responsable y guarda con los datos que cargó antes del cambio de Lucía. Si aceptamos su PUT completo, la prioridad vuelve a media y nadie se entera: es la actualización perdida, el bug más silencioso de las aplicaciones colaborativas.

La respuesta es el bloqueo optimista del M10 —If-Match y 412— aplicado al campo version:

En el repositorio, la condición viaja dentro del UPDATE: UPDATE tareas SET … version = version + 1 WHERE id = :tareaId AND version = :version RETURNING *. Si otra persona se adelantó, el filtro no encaja, no se actualiza ninguna fila y RETURNING devuelve el conjunto vacío que traducimos a null. Es atómico y no necesita transacción explícita: la misma idea del findOneAndUpdate condicional del 12-01, ahora en SQL.

Qué debe hacer el cliente ante un 412. No recargar en silencio (perdería lo escrito) ni forzar el guardado (volveríamos al principio). Lo correcto: mostrar qué cambió la otra persona, conservar lo que el usuario tenía escrito y ofrecer "conservar lo mío" o "quedarme con lo suyo". Y una mejora barata: si los campos tocados no se solapan (Lucía tocó prioridad, Marc responsable), se puede fusionar automáticamente y avisar. Enviar PATCH con solo los campos modificados, en vez de PUT con la tarea entera, reduce muchísimo la frecuencia de conflictos reales.

La actividad es la fuente de verdad de "qué ha pasado". No es un registro decorativo: es una tabla de solo inserción donde cada cambio del dominio deja un hecho con actor, momento y datos:

Esta tabla se parece mucho al abastecimiento de eventos (event sourcing), donde el estado se reconstruye reproduciendo los hechos. Aquí no llegamos tan lejos: mantenemos el estado actual en tareas y la actividad es un registro paralelo. Es un compromiso deliberado —las consultas siguen siendo triviales— y conviene saber que existe la versión pura por si algún día el requisito es "reconstruye el tablero tal como estaba el martes". Regla de la tabla: nunca se actualiza ni se borra; si algo se registró mal, se registra una corrección. Un historial editable no es un historial.

Notificaciones: el problema de los 40 correos. Marc reorganiza el tablero del Festival: mueve 12 tareas, reasigna 5 y comenta en 3. Si cada hecho dispara un correo, Lucía recibe 20 correos en cuatro minutos y crea un filtro para no volver a ver ninguno: la notificación deja de funcionar. La solución es agrupar y diferir con BullMQ (M10) usando una ventana de silencio —el primer hecho encola un trabajo con retraso y los siguientes se acumulan sin encolar nada nuevo—.

Las preferencias por usuario son parte del diseño, no un extra: canal (correo, en la aplicación, ambos), tipos de hecho que interesan y ventana de agrupación (inmediata, 5 minutos, resumen diario). Un sistema de notificaciones sin preferencias acaba silenciado por completo.

Aquí los proyectos se conectan: la infraestructura del 12-01 —Socket.IO sobre el http.Server, autenticación en el handshake, adaptador de Redis para varios procesos— se reutiliza tal cual, cambiando solo el espacio de nombres (/tablero/v1) y las salas (espacio:<id>). El manejador de espacio:suscribir aplica la misma regla del punto 3: consulta buscarPertenencia, devuelve ESPACIO_NO_ENCONTRADO si no la hay y solo entonces hace socket.join. La pertenencia decide también aquí, y se consulta: nunca se confía en el espacioId que envía el cliente.

Y la emisión no se dispara desde el controlador a mano, sino desde el mismo sitio que ya registra la actividad, un único punto de verdad: el servicio publicarActividad emite actividad:nueva a la sala espacio:<id> de /tablero/v1 —para quien está mirando el tablero ahora mismo— y recorre repositorioEspacios.miembrosInteresados(actividad) llamando a encolarNotificacion para quien no está mirando.

Ojo con un detalle del M10: el io vive en el proceso web y las notificaciones se procesan en el consumidor, así que el adaptador de Redis del 12-01 es lo que permite que una emisión hecha desde cualquier proceso llegue a todos los sockets.

Dos trabajos programados de BullMQ resuelven los vencimientos: uno repetible diario (repeat: { pattern: '0 8 * * *', tz: 'Europe/Madrid' }) que avisa de lo que vence mañana, y uno diferido por tarea que recuerda 24 horas antes de su fecha, con jobId: recordatorio-<tareaId> para que reprogramar sustituya en vez de acumular recordatorios zombis. Como en el 12-03, el consumidor revalida antes de actuar: si la tarea ya está hecha o la fecha cambió, el trabajo se descarta; un trabajo diferido siempre puede ejecutarse en un mundo distinto al que lo creó. El filtro típico del equipo, además, es combinado —"tareas del Auditorio Ribera, en curso o bloqueadas, asignadas a Marc, que vencen esta semana"— y sin el índice adecuado eso es un recorrido secuencial de la tabla.

El índice parcial es una de esas herramientas que pasan desapercibidas: la mayoría de tareas de un espacio veterano están hecha, así que un índice que las excluye es mucho más pequeño y más rápido, y sirve justo a la consulta que se hace cien veces al día. Compruébalo siempre con EXPLAIN ANALYZE (M7): un índice que el planificador no usa es solo coste de escritura. Los informes del espacio son agregación pura:

"Exporta todas las tareas del espacio a CSV" parece trivial hasta que el espacio tiene 200.000 filas históricas. Cargarlas en un array y devolver un respuesta.send gigante consume cientos de megas y bloquea el proceso mientras serializa. Es exactamente el problema que resolvió el M3: fluir, no acumular.

El uso de memoria es constante —unos pocos megas— sea cual sea el volumen.

Con permisos que dependen de una relación, las pruebas de autorización dejan de ser opcionales. La política es pura: se prueba en milisegundos y sin base de datos.

Falta la del punto 5: un PATCH con If-Match: "2" sobre una tarea en versión 3 debe devolver 412. Y la última de las escritas es la que más veces salva de una filtración real: no comprueba un permiso concreto, comprueba que el listado no se cuela. Añádela para cada endpoint de listado que exista.

• Comprobar la pertenencia en el controlador después de cargar el recurso. Funciona hasta que alguien añade un endpoint y se olvida. Empuja el filtro a la consulta del repositorio.
• Devolver 403 cuando el usuario no es miembro. Un 403 confirma que el espacio existe; para recursos privados, 404. Y no aceptes PUT sin If-Match: es abrir la puerta a la actualización perdida, así que devuelve 428 si falta la precondición.
• Renumerar la lista entera al arrastrar. Posiciones fraccionarias, con recompactación como excepción. Y no actualices ni borres filas de actividad: deja de ser fuente de verdad en el momento en que es editable.
• Notificar cada hecho por separado. El usuario silencia el canal y pierdes el único medio de avisarle.
• Consejo: incluye el idPeticion (M11) en cada fila de actividad. Cuando alguien pregunte "¿por qué esta tarea cambió de responsable?", podrás cruzar el hecho con los registros de pino de esa petición exacta.

1. Dependencias sin ciclos. Implementa crearDependencia(tareaId, dependeDeId) que rechace con 409 cualquier dependencia que cree un ciclo (A → B → C → A). Escribe pruebas para el ciclo directo y el indirecto.

2. Reasignación masiva con actividad. Implementa POST /espacios/:id/tareas/reasignar que cambie el responsable de N tareas en una transacción, registre un hecho por tarea y produzca un solo correo agrupado. Prueba que el destinatario recibe un envío y no N.

3. Vista "mi día". Devuelve las tareas del usuario que vencen hoy o están vencidas, de todos sus espacios, ordenadas por prioridad y vencimiento, en una sola consulta que use el índice parcial.

1. Dependencias sin ciclos

La prueba encadena B→A y C→B y comprueba que A→C se rechaza con DEPENDENCIA_CIRCULAR. Con grafos grandes el recorrido por consultas encadenadas se paga caro: la alternativa es un WITH RECURSIVE que resuelve el alcance en un solo viaje.

2. Reasignación masiva agrupada

El agrupamiento sale gratis: los N hechos se acumulan en la lista de Redis y comparten el mismo jobId resumen-<destinatarioId>, así que BullMQ mantiene un trabajo diferido. La prueba espía servicioCorreo.enviar, adelanta el reloj VENTANA_AGRUPACION_MS y verifica callCount === 1 con un asunto que incluye "12 novedades".

3. Vista "mi día"

El EXISTS sobre miembros parece redundante —la tarea ya está asignada al usuario— pero cubre el caso de alguien expulsado del espacio que conserva tareas asignadas: sin él seguiría viendo trabajo de un espacio al que ya no pertenece. El WHERE estado <> 'hecha' encaja con el índice parcial del punto 8; confírmalo con EXPLAIN ANALYZE.

La herramienta interna cierra los cuatro proyectos con el reto que solo aparece cuando varias personas comparten los mismos objetos. Has visto que el RBAC del Módulo 8 no muere, se extiende: la política sigue siendo una función pura, pero recibe la pertenencia además del rol, y —la parte que de verdad protege— la comprobación se empuja al WHERE del repositorio, para que devolver un recurso ajeno sea imposible en lugar de improbable.

Has resuelto la actualización perdida con bloqueo optimista y una respuesta 412 que le da al cliente todo lo necesario para reconciliar; has ordenado listas sin reescribirlas con posiciones fraccionarias, conociendo su límite y su plan B; y has construido un registro de actividad inmutable que sirve a la vez de historial, de disparador del tiempo real del 12-01 y de origen de unas notificaciones agrupadas. Con esto quedan construidos los cuatro productos satélite de Escena Viva. La última lección del curso no añade otro proyecto: recoge el viaje entero, convierte lo aprendido en una lista de comprobación de puesta en producción y en un marco para tomar decisiones técnicas, y traza con honestidad hacia dónde seguir cuando el curso termine.