docs: what is left (chapter 10)

What it takes to call the product done in production, the known bugs and
debt, the next features in order and what is set aside for now. The note
on chat notifications moves here from the docs index. Word and PDF
regenerated.

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

docs/10-futuro.md

@@ -0,0 +1,66 @@
+# 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                                                                                                                                                                                                |
+| -------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| Averiguar por qué se pierde el tiempo real en producción | La ficha del ticket ya no depende de él (se recarga tras cada cambio propio), pero el tablero, la actividad y la campana sí | Sospecha: el WebSocket manda el token solo al conectar (`connectionParams`); cuando caduca o se renueva, la conexión sigue viva pero puede dejar de recibir. Dejar una pestaña abierta más que la vida del token |
+| 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.
+- **Arrastrar a una columna prohibida**: la tarjeta se queda en la última columna permitida por la que pasó el cursor
+  (comportamiento de `@angular/cdk/drag-drop`). Debería volver a su sitio.
+- **Tamaño de la web**: el paquete inicial supera en ~130 kB el aviso de 2 MB, y los estilos de la ficha del ticket
+  (`issue.page.scss`) pasan de los 8 kB. Mirar qué entra en el paquete inicial (`marked` y `dompurify` deberían ir solo
+  con la ficha) y sacar las reacciones a su componente.
+- **Imágenes pegadas**: también aparecen en la lista de adjuntos del ticket, y si se borran del texto el adjunto sigue
+  ahí.
+- **Límite de propuestas por instancia**: vive en memoria, así que con varias instancias de la API es aproximado.
+  Pasarlo a Redis si hay más de una.
+- **Votos por REST**: dan el total (`votes`) pero no si he votado yo (`voted` solo está en GraphQL).
+- **Seguimiento**: los tickets que ya existían no se apuntan a quien los creó o los tiene asignados (solo los nuevos).
+- **Borrar un proyecto** no borra su documento de integración con Git (`git_integrations`); no molesta, pero queda.
+- **Aviso de lint** en `automation-rules.ts` (una aserción `!`), anterior a estos cambios.
+- **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 de propuestas**: hoy una propuesta llega como ticket con la etiqueta «propuesta», pero nadie recibe aviso.
+   Avisar a propietarios y admins, y quizá una bandeja para revisarlas.
+3. **Propuestas y votos en la web pública** (la landing): el escaparate ya trae `proposals` (si acepta, dónde está el
+   formulario y las más votadas) y los votos de la hoja de ruta; falta mostrarlos.
+4. **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.
+5. **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.
+6. **Proyectos de la landing que ya existen**: hoy el tablero en TaskStream solo se abre al crear el proyecto; poder
+   abrirlo después desde el panel.
+
+## 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.