# 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. - **Tamaño de la web**: el paquete inicial supera en ~130 kB el aviso de 2 MB por `@pi/ui`, que registraba Chart.js al importarse e importaba `lodash` entero. Ya está corregido en `pireon-ui` (con él, 1,90 MB); falta publicar esa versión en Nexus y subir aquí `@pi/ui`. - **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 orden de lo que más aportaría: 1. **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 que ya existe; - redactar las notas de versión en lenguaje natural a partir del borrador. 2. **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. 3. **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. ## 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`.