task-stream/docs/10-futuro.md

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).
• 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

Elegidas para la próxima tanda

En este orden:

1. Calendario suscribible (ICS): una URL privada por persona con las fechas límite, los sprints y las releases de sus proyectos, para Google Calendar, Outlook o Apple Calendar. La URL lleva un token propio (revocable), no el de sesión.
2. Notificaciones push (Web Push): los avisos de la campana como aviso del sistema, aunque la pestaña esté cerrada. Un service worker en la web (que la deja instalable como PWA), «Activar avisos» en los ajustes de notificaciones, las suscripciones de cada persona guardadas en la API y el envío con Web Push (claves VAPID, dos variables nuevas). En iPhone solo con la web instalada en la pantalla de inicio (iOS 16.4+).
3. Campos personalizados por proyecto: «Navegador», «Cliente», «Entorno»… de texto, número, fecha o lista de opciones, definidos en Configuración; editables en la ficha, filtrables y como columna en la vista de lista.

Valoradas para después

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 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 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.

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.
• 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.

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.

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.