task-stream/docs/01-vision-general.md

1. Visión general

Qué resuelve

Necesidad	Cómo se resuelve
🐛 Bugs	Tickets de tipo BUG con prioridad, área y etiquetas
🌍 Públicos	Un proyecto público se puede leer sin iniciar sesión (web, GraphQL y REST): tablero, tickets, comentarios, releases, actividad y estadísticas; «Explorar» los lista
🗑️ Borrar	El propietario borra un proyecto confirmando su clave; tickets, comentarios, releases y enlaces desde otros proyectos se borran en cascada (sagas) y la clave queda libre
🧩 Configuración	Cada proyecto tiene sus estados (con categoría, color y motivo obligatorio), transiciones, tipos de ticket y áreas; lo usado se archiva, no se borra
🎨 Cambios de UI	Tipo UI_CHANGE con enlace al frame de Figma (validado contra figma.com)
⚙️ Features	Tipo FEATURE siguiendo el workflow completo
🧪 QA	Por defecto, READY_FOR_QA → IN_QA → DONE / QA_FAILED; fallar QA exige un motivo
🚀 Releases	Versiones a las que se asignan tickets; no se publican con tickets sin terminar (salvo forzando)
📝 Notas de versión	Borrador en Markdown con los tickets terminados por tipo, editable y copiable, también tras publicar
👥 Asignaciones	Solo a miembros del proyecto; panel de carga por persona
💬 Comentarios	Decisiones y explicaciones dentro del ticket, con @menciones; el autor edita, el admin modera
🔎 Vistas	El tablero se filtra por texto, persona (o sin asignar), tipo, prioridad, área y release; los filtros se guardan como vistas propias o compartidas con el proyecto
🚦 WIP y carriles	Límite de trabajo en curso por estado (la columna se marca al pasarse) y tablero agrupable por persona, épica, prioridad o tipo
🎲 Estimación	Puntos por ticket (escala 0-1-2-3-5-8-13-21) en la ficha, las tarjetas, las columnas y el backlog; velocidad por sprint y aviso si un sprint planificado supera la media
🏃 Sprints	Iteraciones con fechas y objetivo, una en curso por proyecto, con burndown (tickets o puntos) y traspaso de lo pendiente al cerrar
📋 Backlog	Lo pendiente de empezar, en el orden en que se va a coger; se reordena arrastrando y el tablero sigue ese orden
🗑️ Papelera	Borrar un ticket lo manda a la papelera (quien lo abrió o un admin); se recupera durante 30 días y luego se borra del todo
☑️ En bloque	Selecciona varios tickets del backlog y cámbiales a la vez estado, persona, sprint, prioridad o etiqueta
⌨️ Atajos y búsqueda	Ctrl/⌘ K o / busca tickets y proyectos de todos tus proyectos; g b, g k, g s, g r navegan, c crea, e edita, ? los lista
🗺️ Hoja de ruta	Las épicas en el tiempo (fecha de inicio y límite), con los sprints y las releases como referencias
🧩 Desglose	Épicas → tickets → subtareas (tres niveles), con su progreso; y una checklist dentro de cada ticket para los pasos pequeños
👀 Seguir	Cualquier miembro sigue los tickets que le interesan; quien comenta, los sigue solo
🔔 Avisos	Campana con lo que te concierne (asignaciones, cambios de estado, QA fallido, comentarios), en vivo y opcionalmente por correo
⏰ Recordatorios	Aviso (y correo, si se quiere) el día antes, el mismo día y al vencer la fecha límite, a quien lo tiene y a quien lo sigue; las tarjetas marcan lo que vence
📎 Adjuntos	Capturas, logs y vídeos en el ticket o bajo un comentario; arrastrar, elegir o pegar con Ctrl+V; miniaturas de las imágenes
🔗 Relaciones	BLOCKS, DEPENDS_ON, TESTS, DUPLICATES, RELATES_TO, también entre proyectos (FE ↔ BE ↔ QA)
🌿 Git	Webhook para GitHub, Gitea o GitLab: commits, ramas y pull requests que nombran un ticket (WEB-12) aparecen en su ficha
🧾 Plantillas	Cada tipo de ticket puede traer una descripción inicial y una checklist que se aplican al crearlo
🤖 Automatizaciones	Reglas «cuando… si… entonces…»: al crear, mover, asignar, comentar o fusionar una PR, mover, asignar, etiquetar, priorizar, comentar o meter en el sprint
📡 Webhooks	Un POST firmado (HMAC-SHA256) a otro sistema cuando pasa algo: tickets, comentarios, releases, sprints; con prueba y último envío
📦 Importar/exportar	Todos los tickets a CSV; importar un CSV propio o una exportación de Jira, con vista previa de lo que se va a crear
🏠 Inicio	«Mi trabajo»: mis tickets en todos los proyectos, por categoría (QA fallidos primero), lo que espera QA, próximas releases e «Ir a…» por clave
📊 Seguimiento	Panel con contadores, flujo por estado, el equipo con sus tickets abiertos (enlaza a su tablero), feed de actividad e historial por ticket
📈 Estadísticas	Creados vs. resueltos, flujo acumulado, burnup de releases, tiempos de ciclo y entrega, tasa de fallo en QA y resueltos por persona
⚡ Tiempo real	Tablero, comentarios, actividad, releases y membresías se actualizan solos (GraphQL subscriptions)

Los usuarios no se gestionan aquí: vienen del servidor de identidad Pireon (Swagger). TaskStream gestiona proyectos, membresías y roles por proyecto (OWNER, ADMIN, MEMBER, VIEWER).

Stack

Pieza	Tecnología
Monorepo	Nx 23
API	NestJS 11, @nestjs/cqrs, GraphQL (Apollo Server 5, code-first) con subscriptions graphql-ws
Escritura	PostgreSQL 17: event store + tablas de lookup (TypeORM)
Escritura → lectura	Redis 7: Redis Stream (eventos) y pub/sub (tiempo real); también caché de sesiones
Lectura	MongoDB 8: vistas desnormalizadas (Mongoose)
Identidad	Pireon (OAuth2 / Laravel Passport)
Cliente	Angular 22 (standalone, zoneless, Signal Forms), NgRx Signals (plugin de eventos), Apollo Angular, @pi/ui
Tests	Jest (API), Vitest (web), e2e de la API contra Docker
Despliegue	Docker: imagen Node de la API y nginx para la web

Estructura del monorepo

apps/
  api/          composición de la API (NestJS): config, GraphQL, conexiones, e2e
  web/          composición del cliente (Angular): rutas, providers, estilos, nginx
  mcp/          servidor MCP para asistentes de IA (NestJS), consume la API REST
libs/
  api/{shared,identity,tracker}/{domain,application,infrastructure,presenters}
  web/{shared,identity,tracker}/{domain,application,infrastructure,presenters}   (+ web/shared/ui)
docs/           esta documentación
codegen.ts      tipos GraphQL del cliente generados desde apps/api/schema.gql
Dockerfile      tres destinos: api, web y mcp
docker-compose.yml

API y web comparten la misma estructura: contexto (shared, identity, tracker) × capa (domain, application, infrastructure, presenters). Los imports siguen el mismo patrón: @task-stream/api/tracker/domain, @task-stream/web/tracker/application…

Contextos

• shared: piezas comunes. En la API, event store, Redis, VersionedAggregateRoot, errores de dominio. En la web, el cliente GraphQL y la integración de @pi/ui.
• identity: quién es el usuario (Pireon), sesiones, inicio de sesión y autorización global.
• tracker: el producto (proyectos, tickets, comentarios, releases, actividad).