pigui/task-stream
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
0e301ad545de67648ae14fc690f857a13ca5ec91
task-stream/libs/api/tracker/application/README.md
Josep Piguillem 0e301ad545 feat: per-project workflow settings, statistics and "my work" home 
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>
2026-10-06 20:53:45 +02:00

1.6 KiB
Raw Blame History

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.

Comandos

npx nx lint api-tracker-application
npx nx test api-tracker-application    # Jest

Reglas de dependencia entre capas: Arquitectura.