Files
task-stream/docs/01-vision-general.md
Josep Piguillem 4148335457 feat: bulk edit tickets
Select several tickets in the backlog and change their status, assignee,
sprint, priority or labels at once. Each ticket goes through the normal
rules and may refuse on its own; the result says which did.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-08 18:26:53 +02:00

9.7 KiB
Raw Blame History

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
☑️ En bloque Selecciona varios tickets del backlog y cámbiales a la vez estado, persona, sprint, prioridad o etiqueta
🗺️ 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
📎 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).