Files

Josep Piguillem c2928d2385 feat: several Git repositories per project

A project keeps a list of repositories (api, web, admin…), each with its
own secret, instead of a single webhook secret. They all call the same
URL; the secret that verifies the signature tells which one it was, and
every commit, branch or pull request is linked with its repository's
name (shown on the ticket and in the MCP). Rotating or removing one
leaves the others alone, and what it linked stays.

A project that had turned the single webhook on keeps its secret, as a
repository named "principal".

API: the enable/disable endpoints and mutations give way to adding a
repository, rotating its secret and removing it (REST and GraphQL). The
web settings card lists the repositories. Docs, Word and PDF updated.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

2026-10-09 10:39:59 +02:00

src

feat: several Git repositories per project

2026-10-09 10:39:59 +02:00

eslint.config.mjs

first commit

2026-10-03 13:40:26 +02:00

jest.config.cts

first commit

2026-10-03 13:40:26 +02:00

project.json

feat: per-project workflow settings, statistics and "my work" home

2026-10-06 20:53:45 +02:00

README.md

feat: public projects, project deletion and sagas

2026-10-07 07:04:20 +02:00

tsconfig.json

first commit

2026-10-03 13:40:26 +02:00

tsconfig.lib.json

first commit

2026-10-03 13:40:26 +02:00

tsconfig.spec.json

first commit

2026-10-03 13:40:26 +02:00

README.md

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 el acceso (ReadAccess: miembros, o cualquiera si el proyecto es público; viewerId null = anónimo); 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.
sagas/: ProjectDeletionSaga (cascada al borrar un proyecto y sus tickets), ReleaseArchivedSaga (los tickets sin terminar salen de una release archivada) y UserDeactivatedSaga (desasigna los tickets abiertos de un usuario que Pireon desactiva). Las ejecuta el EventsBridge; sus comandos son internos e idempotentes. Tests en sagas.spec.ts.
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.