Josep Piguillem
0b65c1c912
Files are uploaded over REST, stored on disk (a volume in Docker) and recorded on the ticket as events; the bytes are written first, so no attachment ever points at a missing file. Only images, video, audio, PDF and plain text are shown inline, everything with nosniff and a sandbox CSP. The web shows thumbnails, uploads by drag and drop or by pasting a screenshot, and attaches files to new comments. Also adds `nx run api:contracts`, which writes schema.gql and openapi.json without starting the API or any database. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
68 lines
6.5 KiB
Markdown
68 lines
6.5 KiB
Markdown
# 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) |
|
||
| 👥 Asignaciones | Solo a miembros del proyecto; panel de carga por persona |
|
||
| 💬 Comentarios | Decisiones y explicaciones dentro del ticket; el autor edita, el admin modera |
|
||
| 📎 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) |
|
||
| 🏠 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](https://oauth.pireon.dev/api/documentation)). 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).
|