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>
TaskStream
Alternativa a Jira para equipos de desarrollo: proyectos, tickets (bugs, features, cambios de UI, tareas y QA), releases, comentarios y relaciones entre tickets, en tiempo real.
- API: NestJS + GraphQL y REST con OpenAPI (Swagger, para otras apps), arquitectura hexagonal, CQRS y event sourcing (escritura en PostgreSQL, lectura en MongoDB, Redis entre ambas).
- Web: Angular 22 + NgRx Signals (patrón de eventos) +
@pi/ui, con la misma arquitectura. - Usuarios: los gestiona Pireon.
Empezar
docker compose up -d --build # web en http://localhost:8080
Para entrar hacen falta los clientes OAuth de Pireon en .env: uno authorization_code (PIREON_CLIENT_ID /
_SECRET, «Entrar con Pireon») y uno password (PIREON_PASSWORD_CLIENT_ID / _SECRET, email y contraseña). Ver
Autenticación. Para desarrollar:
npm install # @pi/ui necesita el token del Nexus de Pireon en ~/.npmrc
docker compose up -d postgres mongo redis
cp .env.example .env
npx nx serve api # http://localhost:3000/graphql · REST: /api/docs
npx nx serve web # http://localhost:4200
Documentación
| Visión general | Funcionalidades, stack y estructura del monorepo |
| Arquitectura | Capas, CQRS, event sourcing, flujo escritura → lectura y tiempo real |
| API | Dominio, workflow de tickets, eventos, GraphQL y REST (OpenAPI) |
| Cliente web | Stores con eventos, GraphQL y @pi/ui |
| Autenticación | Tokens de Pireon, login en el navegador y webhooks |
| Desarrollo | Comandos, tests, cómo añadir una funcionalidad y problemas conocidos |
| Despliegue | Docker, variables de entorno y escalado |
| Decisiones | Por qué está hecho así |
Cada librería de libs/api/* y libs/web/* tiene su propio README.md.
Estructura
apps/api apps/web
libs/api/{shared,identity,tracker}/{domain,application,infrastructure,presenters}
libs/web/{shared,identity,tracker}/{domain,application,infrastructure,presenters} (+ web/shared/ui)
docs/
npx nx run-many -t lint test build # todo
npx nx e2e api # flujo completo contra Docker
npx nx graph # dependencias entre proyectos