# 10. Lo que queda Lo pendiente, ordenado de más a menos urgente: primero lo que hace falta para dar el producto por terminado en producción, después los fallos y la deuda conocidos y al final las ideas. Cada punto dice qué es, por qué importa y, cuando hay pistas, por dónde empezar. ## 10.1 Para dar el producto por terminado | Qué | Por qué | Por dónde empezar | | ---------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Comprobar en producción que el tiempo real ya no se pierde | Ya hay _ping_ cada 10 s, reconexión si no hay respuesta y recarga de cada pantalla al reconectar, pero no se ha probado allí | Dejar una pestaña abierta más que la vida del token y tras suspender el portátil, y mover tickets desde otra. Si aún falla, mirar el token de `connectionParams`, que solo se manda al conectar | | Pruebas de navegador en la integración continua | Los fallos del tablero (no se podía arrastrar entre columnas) y de la ficha (no se refrescaba) solo se vieron usándolo | Ya existe la receta: API real con usuarios simulados (`IdentityProvider` sustituido), `nx serve web` y Playwright con la sesión en `localStorage` (`task-stream.session`). Convertirla en `apps/web-e2e` | | Copias de seguridad de Postgres y Mongo | Postgres guarda el event store, la fuente de verdad; Mongo se puede reconstruir desde él, Postgres no | Copias programadas en Dokploy y **una restauración de prueba** | | Limpiar los datos de prueba de producción | DEMO, TEST y los tickets de las pruebas del MCP | Borrar los proyectos desde Configuración (borrado definitivo con su clave) | | Registrar el webhook del cliente de contraseña en Pireon | Sin él, revocar un token de quien entra con contraseña no se nota hasta que caduca la caché | Solo si `PIREON_PASSWORD_CLIENT_ID` tiene valor: webhook en ese cliente y su secret en `PIREON_PASSWORD_WEBHOOK_SECRET` (ver [Autenticación](05-autenticacion.md)) | | Una versión 1.0 | Un punto fijo al que volver | Desplegar todo, etiquetar `v1.0.0` y redactar la lista de cambios (las notas de versión de TaskStream dan el borrador) | | Revisión de seguridad | Hay rutas sin sesión (proyectos públicos, escaparate, propuestas) y un MCP abierto a Internet | Permisos por rol, qué ve un anónimo, límites de peticiones (solo las propuestas tienen), CORS, cabeceras | | Registro de errores en producción | Hoy un fallo solo se conoce si alguien avisa | Sentry (o similar) en la API, la web y el MCP | ## 10.2 Fallos y deuda conocidos - **Error al crear subtareas en producción**: lo reportó el usuario y no se reprodujo en local; con el arreglo de la ficha la lista ya se refresca, pero falta el mensaje exacto si vuelve a salir. - **Imágenes pegadas**: ya no salen en la lista de adjuntos, pero si se borran del texto el adjunto sigue guardado. - **Seguimiento**: los tickets que ya existían no se apuntan a quien los creó o los tiene asignados (solo los nuevos). - **El MCP no hace el flujo OAuth del protocolo**: el cliente tiene que llevar un token de Pireon en la cabecera y renovarlo a mano cuando caduca. ## 10.3 Siguientes funcionalidades ### En curso, en este orden 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`). 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. 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 - **Resumen diario por correo**: lo asignado, lo que vence hoy y lo que ha cambiado en lo que sigues, en un solo correo. - **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. - **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 Mucho trabajo para lo que aportan hoy; se pueden recuperar si alguien los necesita: - **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 - Tiempo real: _ping_ y reconexión del WebSocket, y recarga de lo que se ve al reconectar. - Arrastrar a una columna prohibida devuelve la tarjeta a su sitio. - Reacciones y «Bloqueado» en componentes propios (los estilos de la ficha vuelven a caber en 8 kB). - Límite de propuestas en Redis, válido con varias instancias. - Aviso `PROPOSED` a propietarios y admins cuando llega una propuesta. - `voted` también por REST. - Borrar un proyecto borra su integración con Git. - Sin avisos de lint. - La web pública (landing-web) enseña las propuestas más votadas, el enlace al formulario y los votos de la hoja de ruta. - Un proyecto de la landing creado sin tablero puede abrirlo después: «Crear en TaskStream» en su ficha o `taskstream: true` en un `PATCH`. - Paquete inicial de la web de 2,13 MB a 1,88 MB con `@pi/ui` 0.0.4, que ya no registra Chart.js al importarse ni depende de `lodash`. - Descripciones y comentarios con editor visual (guardado en Markdown), con menciones y capturas pegadas. - Ids: `uuid` en todas las tablas de Postgres (el orden de los eventos en `seq`) y, en Mongo, `id` con el uuid del dominio más el `_id` `ObjectId` propio. - Enlazar tickets y colgar de un padre eligiendo en un selector con búsqueda; casillas de `@pi/ui` en toda la web. - Mover tickets entre releases: «Release…» en la edición en bloque, filtro por release en la lista (también desde cada release, «Ver en la lista»), y al archivar una release, elegir adónde va lo pendiente. - Calendario suscribible (iCalendar) desde «Mi trabajo»: tickets con fecha, sprints y releases, con URL secreta renovable. - Notificaciones push (Web Push) en cada dispositivo, con la web instalable. - 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.