feat(web): dependencies between epics on the roadmap

Arrows from an epic to the ones that wait for it («bloquea» / «depende
de»), drawn over the bars; dashed red, plus a note in words, when one
starts before the epic blocking it ends. The next batch and the ideas
kept or dropped are written down in docs/10-futuro.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

docs/10-futuro.md

@@ -30,26 +30,48 @@ cuando hay pistas, por dónde empezar.
 
 ### En curso, en este orden
 
-4. **Dependencias en la hoja de ruta**: las relaciones «bloquea» / «depende de» entre épicas, como flechas en la vista
-   de calendario, para ver qué retrasa a qué.
-5. **Burndown y velocidad de sprint**: puntos pendientes día a día durante el sprint y puntos cerrados por sprint, para
+1. **Burndown y velocidad de sprint**: puntos pendientes día a día durante el sprint y puntos cerrados por sprint, para
    planificar el siguiente con datos (el historial de estados ya está en `issue_timeline`).
-6. **Plantillas de proyecto**: crear un proyecto copiando de otro los estados, transiciones, tipos, áreas,
-   automatizaciones y etiquetas.
-7. **Sincronizar con issues de Gitea o GitHub**: hoy los commits y PR se enlazan a tickets; además, que un issue del
-   repositorio cree o actualice un ticket, y al revés.
-8. **Vistas guardadas en «Mi trabajo»**: montar la portada con filtros guardados de varios proyectos («Bugs críticos de
-   todos mis proyectos», «Lo que revisa QA esta semana»…).
-9. **Exportar e imprimir un sprint o una release**: un PDF con los tickets, su estado y las notas, para un cliente o
+2. **Plantillas de proyecto**: crear un proyecto copiando de otro los estados, transiciones, tipos, áreas, campos
+   personalizados, automatizaciones y etiquetas.
+3. **Exportar e imprimir un sprint o una release**: un PDF con los tickets, su estado y las notas, para un cliente o
    para archivar.
-10. **Asistente en la web** (la base ya está en el MCP): resumir un ticket largo con sus comentarios; al crear un
-    ticket, sugerir tipo, prioridad y área y avisar si se parece a otro; redactar las notas de versión a partir del
-    borrador. Pendiente de decidir la clave de la API de Claude y su coste.
-11. **Avisos a Discord, Slack o Telegram**: los webhooks salientes mandan JSON en bruto, que esos chats no muestran
-    bien. Una integración por canal (o un formato por destino en los webhooks) mandaría mensajes ya legibles: «Ana
-    movió WEB-12 a En revisión», con enlace.
-12. **Conector de claude.ai**: el MCP necesitaría el flujo OAuth del protocolo, y Pireon publicar su metadata de
-    autorización y admitir el registro dinámico de clientes.
+
+Y en el panel del proyecto:
+
+4. **Sprint en curso**: días que quedan, puntos hechos y pendientes, y aviso si al ritmo actual no llega.
+5. **Tickets en riesgo**: vencidos, que vencen esta semana, bloqueados y atascados (días sin moverse en un estado en
+   curso), cada grupo con enlace a la lista filtrada.
+6. **Antigüedad de lo abierto**: cada ticket en curso por los días que lleva en su estado, con el umbral habitual del
+   proyecto (p85 del tiempo de ciclo).
+7. **Cuellos de botella**: días medios en cada estado y columnas por encima de su límite WIP.
+8. **Próximas releases con previsión**: progreso, fecha objetivo y fecha probable según el ritmo real (Monte Carlo),
+   con semáforo.
+9. **Qué ha cambiado desde tu última visita**: nuevos, cerrados, devueltos por QA y menciones.
+10. **Carga del equipo en puntos**: asignado frente a lo que cada persona suele cerrar por sprint, con aviso de
+    sobrecarga y sus bloqueados.
+11. **Salud del backlog**: sin estimar, sin área, sin asignar y sin tocar en 90 días, con enlace a la lista filtrada.
+12. **Calidad**: bugs abiertos por prioridad y su tendencia, devoluciones de QA por área y bugs abiertos en los 14 días
+    siguientes a cada release.
+13. **Desglose por campo personalizado**: tickets abiertos según un campo de opciones a elegir («bugs por
+    navegador»).
+
+### Aceptadas, para después de esta tanda
+
+- **Sincronizar con issues de Gitea o GitHub**: que un issue del repositorio cree o actualice un ticket, y al revés.
+- **Vistas guardadas en «Mi trabajo»**: filtros guardados de varios proyectos («Bugs críticos de todos mis
+  proyectos»).
+- **Búsqueda con lenguaje de consulta**: `estado:abierto asignado:yo navegador:Safari prioridad>=alta`, guardable como
+  vista.
+- **Definición de «Hecho»**: no pasar a un estado `DONE` con la lista de comprobación a medias (salvo un admin).
+- **Entornos de despliegue**: en qué entorno está cada ticket (pruebas, producción), desde los avisos de la
+  integración continua.
+- **Equipos dentro del proyecto**: asignar a un equipo y mencionarlo (`@frontend`).
+- **Presencia**: ver quién está mirando o editando el mismo ticket.
+- **Rol «invitado»**: solo ve los tickets en los que participa (clientes, externos).
+- **Página pública de novedades**: las notas de versión publicadas en una página por proyecto, con RSS.
+- **Vista de cartera**: progreso de épicas y releases de todos los proyectos en una página.
+- **Archivar un proyecto**: queda en solo lectura en lugar de borrarlo.
 
 ### Otras ideas apuntadas, sin decidir
 
@@ -57,8 +79,13 @@ cuando hay pistas, por dónde empezar.
 - **Tickets recurrentes**: «revisar copias cada lunes», creados solos con la plantilla del tipo.
 - **Crear tickets por correo**: una dirección por proyecto; lo que llega es un ticket (con adjuntos) y las respuestas,
   comentarios. Necesita un buzón de entrada.
-- **Tiempo en cada estado**: cuánto pasa un ticket en «En revisión» o «En QA», y dónde se atascan.
-- **Página pública de novedades**: las notas de versión publicadas en una página por proyecto, con RSS.
+- **Posponer un ticket**: «recuérdamelo el jueves».
+- **Reunión diaria**: qué cerró cada uno ayer, qué tiene hoy y qué le bloquea, sacado del historial.
+- **Requisitos al cambiar de estado**: campos obligatorios para entrar en un estado (estimación para «En curso»…).
+- **Plazos por prioridad**: «lo crítico, en 24 h», con aviso antes de vencer.
+- **Matriz impacto/esfuerzo** para ordenar el backlog.
+- **Planning poker** y **retrospectiva del sprint** (las acciones se convierten en tickets).
+- **Avisar a quien propuso** cuando su propuesta se hace o se descarta.
 
 ## 10.4 Descartado por ahora
 
@@ -67,6 +94,11 @@ Mucho trabajo para lo que aportan hoy; se pueden recuperar si alguien los necesi
 - **Registro de horas** dedicadas a cada ticket.
 - **Objetivos u OKR** por encima de las épicas.
 - **App móvil**: la web ya se adapta a pantallas estrechas.
+- **Asistente en la web** (resumir tickets, sugerir tipo, prioridad y área, redactar notas de versión): el MCP ya deja
+  hacerlo desde un cliente de IA.
+- **Avisos a Discord, Slack o Telegram** con mensajes legibles: los webhooks salientes siguen ahí para quien los
+  necesite.
+- **Conector de claude.ai** (OAuth del protocolo en el MCP y registro dinámico de clientes en Pireon).
 
 ## 10.5 Hecho desde la primera versión de esta lista
 
@@ -96,3 +128,5 @@ Mucho trabajo para lo que aportan hoy; se pueden recuperar si alguien los necesi
 - Campos personalizados por proyecto (texto, número, fecha o lista de opciones): se definen en Configuración, se
   editan en la ficha, se ven bajo el título en la lista y se filtran por los de opciones (también por GraphQL, REST y
   MCP).
+- Dependencias en la hoja de ruta: flechas entre las épicas que se bloquean o dependen unas de otras, y aviso cuando
+  una empieza antes de que acabe la que la bloquea.