diff --git a/docs/10-futuro.md b/docs/10-futuro.md new file mode 100644 index 0000000..8176292 --- /dev/null +++ b/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. diff --git a/docs/README.md b/docs/README.md index 790adbc..f2f7a16 100644 --- a/docs/README.md +++ b/docs/README.md @@ -3,26 +3,21 @@ TaskStream es una alternativa a Jira para equipos de desarrollo: proyectos, tickets (bugs, features, cambios de UI, tareas, QA), releases, comentarios y relaciones entre tickets, todo en tiempo real. -| Documento | Para qué | -| ----------------------------------------- | ------------------------------------------------------------------------- | -| [1. Visión general](01-vision-general.md) | Qué hace el producto, stack y estructura del monorepo | -| [2. Arquitectura](02-arquitectura.md) | Hexagonal, CQRS, event sourcing, flujo escritura → lectura y tiempo real | -| [3. API](03-api.md) | Dominio (agregados, workflow, eventos) y la API GraphQL | -| [4. Cliente web](04-cliente-web.md) | Angular, NgRx Signals con eventos, GraphQL y `@pi/ui` | -| [5. Autenticación](05-autenticacion.md) | Pireon: tokens, login en el navegador, sesiones y webhooks | -| [6. Desarrollo](06-desarrollo.md) | Puesta en marcha, comandos, tests y cómo añadir una funcionalidad | -| [7. Despliegue](07-despliegue.md) | Docker, variables de entorno y escalado | -| [8. Decisiones](08-decisiones.md) | Por qué está hecho así (y qué alternativas se descartaron) | -| [9. Servidor MCP](09-mcp.md) | Usar TaskStream desde asistentes de IA (Claude…): herramientas y conexión | +| Documento | Para qué | +| ----------------------------------------- | ----------------------------------------------------------------------------------- | +| [1. Visión general](01-vision-general.md) | Qué hace el producto, stack y estructura del monorepo | +| [2. Arquitectura](02-arquitectura.md) | Hexagonal, CQRS, event sourcing, flujo escritura → lectura y tiempo real | +| [3. API](03-api.md) | Dominio (agregados, workflow, eventos) y la API GraphQL | +| [4. Cliente web](04-cliente-web.md) | Angular, NgRx Signals con eventos, GraphQL y `@pi/ui` | +| [5. Autenticación](05-autenticacion.md) | Pireon: tokens, login en el navegador, sesiones y webhooks | +| [6. Desarrollo](06-desarrollo.md) | Puesta en marcha, comandos, tests y cómo añadir una funcionalidad | +| [7. Despliegue](07-despliegue.md) | Docker, variables de entorno y escalado | +| [8. Decisiones](08-decisiones.md) | Por qué está hecho así (y qué alternativas se descartaron) | +| [9. Servidor MCP](09-mcp.md) | Usar TaskStream desde asistentes de IA (Claude…): herramientas y conexión | +| [10. Lo que queda](10-futuro.md) | Pendiente para cerrar, fallos conocidos, siguientes funcionalidades y lo descartado | Cada librería de `libs/` tiene además su propio `README.md` con su responsabilidad y su contenido. -**Ideas para más adelante** - -- **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. - **Empezar rápido** ```sh diff --git a/docs/TaskStream-Documentacion.docx b/docs/TaskStream-Documentacion.docx index 87748d1..edf8f8e 100644 Binary files a/docs/TaskStream-Documentacion.docx and b/docs/TaskStream-Documentacion.docx differ diff --git a/docs/TaskStream-Documentacion.pdf b/docs/TaskStream-Documentacion.pdf index 63844d8..3856ac4 100644 Binary files a/docs/TaskStream-Documentacion.pdf and b/docs/TaskStream-Documentacion.pdf differ