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>
31 lines
1.6 KiB
Markdown
31 lines
1.6 KiB
Markdown
# api-tracker-application
|
|
|
|
Casos de uso del tracker (CQRS).
|
|
|
|
- **Import**: `@task-stream/api/tracker/application`
|
|
- **Capa**: `application` · **Tags**: `scope:api-tracker`, `type:application`
|
|
|
|
## Contenido
|
|
|
|
- Services: `ProjectsService`, `IssuesService`, `CommentsService`, `ReleasesService`, `ChangesService` (subscriptions),
|
|
`WorkflowsService` (workflow de cada proyecto para presentar tickets, con una caché de 2 s).
|
|
- `commands/`: un fichero por command y otro por handler; cargan con `WriteAccess` (rehydrator) y guardan con `commitAndWait()`.
|
|
- `queries/`: un fichero por query y otro por handler; leen de los puertos `Find*Repository` y comprueban la membresía (`ReadAccess`);
|
|
`SearchMyIssuesQuery` y `GetUpcomingReleasesQuery` cruzan todos los proyectos del usuario («Mi trabajo»).
|
|
- `event-handlers/`: proyecciones (`@EventsHandler`) hacia el read model (incluida la línea temporal de cada ticket),
|
|
notificaciones en tiempo real y feed de actividad.
|
|
- `analytics/`: estadísticas y burnup calculados con funciones puras sobre la línea temporal (con tests).
|
|
- `ports/`: lookups de escritura, `Find*`, `UpsertMaterialized*`, `ReleaseIssuesRepository`, `ChangeFeed`, `UserDirectory`.
|
|
- `TrackerApplicationModule.withInfrastructure(...)`.
|
|
|
|
Cómo añadir un caso de uso: [Desarrollo](../../../../docs/06-desarrollo.md#64-cómo-añadir-una-funcionalidad).
|
|
|
|
## Comandos
|
|
|
|
```sh
|
|
npx nx lint api-tracker-application
|
|
npx nx test api-tracker-application # Jest
|
|
```
|
|
|
|
Reglas de dependencia entre capas: [Arquitectura](../../../../docs/02-arquitectura.md#21-capas-hexagonales).
|