Files

Josep Piguillem 0d158a2ed7 feat: dashboard forecasts releases, tells what changed and weighs the load

The insights reading grows (GraphQL insights(since:), REST ?since=, MCP):
- planned releases with a likely (p50) and safe (p85) finish date from a
  Monte Carlo over the last six weeks of finished work, one after another,
  and a verdict against their target;
- with `since` (the viewer's last visit, kept in the browser): tickets
  created, finished and sent back from QA, and their mentions;
- each person's open points against what they closed per sprint lately;
- open tickets without estimate, area or assignee, or untouched for 90
  days, each count opening the list filtered (new noEstimate, noArea and
  updatedBefore filters).

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

2026-10-15 12:50:24 +02:00

11 KiB

Raw Blame History

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)
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).
Escrituras a la vez en un ticket: si una saga (por ejemplo, apuntar como seguidor a quien se asigna) escribe en el mismo ticket justo cuando alguien lo cambia, la petición de esa persona recibe un 409 y hay que repetirla. Con la máquina muy cargada salta en las pruebas e2e de vez en cuando. Reintentar sola la orden ante un ConcurrencyError.
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

En el panel del proyecto:

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.
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.
Plantillas de proyecto: al crear uno, «Empezar con la configuración de» otro que administras copia sus estados, transiciones, tipos, áreas, campos personalizados y automatizaciones. (El burndown y la velocidad de sprint ya existían, en Sprints.)
Informe para imprimir (o guardar en PDF) de un sprint o una release, desde Sprints y Releases.
Panel del proyecto, primera parte: sprint en curso (¿llega a tiempo?), tickets en riesgo (vencidos, que vencen esta semana, bloqueados y atascados), antigüedad de lo que está en curso y cuellos de botella. También por REST, GraphQL y MCP (get_project_insights).
Panel del proyecto, segunda parte: lo que ha cambiado desde tu última visita, previsión de las próximas releases al ritmo real (Monte Carlo), carga del equipo en puntos y salud del backlog con enlaces a la lista filtrada.

11 KiB Raw Blame History