Josep Piguillem
0e301ad545
Per-project settings (owners/admins, «Configuración» tab):
- Statuses with category (TODO, IN_PROGRESS, QA, DONE, CANCELLED), colour and
"requires reason"; configurable transitions; ticket types (icon, colour) and
areas. Defaults are the previous fixed values; projects created before keep
them without migration.
- Values are archived, never deleted: tickets, history and statistics keep
referring to them. Validated in the domain (ProjectSettingsChangedEvent).
- Releases, board, tracking and "my work" use categories, so custom statuses
keep working. Status changes carry name/category metadata for history.
- GraphQL: status/type/area are strings (breaking for clients sending enum
literals); Project.settings, updateProjectSettings, statusCategory,
myIssues(categories). REST: PUT /projects/{project}/settings, category filters.
- Read model: statusCategory on issues (backfilled at startup).
Statistics («Estadísticas» tab):
- New issue_timeline projection; pure functions compute created vs resolved,
cumulative flow, cycle/lead time (avg + p85), throughput per person, QA
pass/fail and release burnup. GraphQL Project.analytics(days),
Release.burnup; REST /projects/{project}/analytics, /releases/{id}/burnup.
- Web: SVG charts with validated light/dark palette, crosshair tooltip,
keyboard navigation, legend and data table.
Home "Mi trabajo": my open tickets across projects grouped by category (QA
failures first), tickets waiting for QA, upcoming releases and "Ir a…".
Tests: domain/application specs, e2e scenario for settings and analytics,
facade tests. Docs, READMEs, schema.gql/openapi.json and Word/PDF updated.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Documentación de TaskStream
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 | Qué hace el producto, stack y estructura del monorepo |
| 2. Arquitectura | Hexagonal, CQRS, event sourcing, flujo escritura → lectura y tiempo real |
| 3. API | Dominio (agregados, workflow, eventos) y la API GraphQL |
| 4. Cliente web | Angular, NgRx Signals con eventos, GraphQL y @pi/ui |
| 5. Autenticación | Pireon: tokens, login en el navegador, sesiones y webhooks |
| 6. Desarrollo | Puesta en marcha, comandos, tests y cómo añadir una funcionalidad |
| 7. Despliegue | Docker, variables de entorno y escalado |
| 8. Decisiones | Por qué está hecho así (y qué alternativas se descartaron) |
Cada librería de libs/ tiene además su propio README.md con su responsabilidad y su contenido.
Empezar rápido
docker compose up -d --build # web en http://localhost:8080
Para entrar hacen falta dos clientes OAuth de Pireon en .env (authorization_code y password, ver
Autenticación).