Tareas pendientes

Trabajo identificado pero no construido — a diferencia de los "Casos especiales" dentro de cada flujo (comportamiento actual, ya implementado), esto es lo que falta. Portado y verificado contra el código el 2026-09-02 desde ecosystem-wiki; el ítem de Dozzle se excluyó porque ya está resuelto (repo logger-dozzle deployado).

Universal Links / App Links

El link de activación por email siempre abre la web (account-activation) — no hay atajo automático a la app instalada. Un scheme custom (petidclient://...) no sirve como link principal porque no tiene fallback si la app no está instalada; hace falta que el SO decida.

La URL del correo sigue siendo https://.../activate?token=... (la de petid-landing)

iOS     → apple-app-site-association en petid-landing (/.well-known/)
        → associatedDomains en app.json de petid-client
Android → assetlinks.json en petid-landing (/.well-known/)
        → intentFilters (autoVerify) en app.json de petid-client

App instalada + dominio verificado → el SO abre la app directo
App no instalada                   → cae en petid-landing (ya funciona hoy)

Config nativa — necesita rebuild EAS (no vale OTA), y la verificación de dominio no se puede probar del todo sin el dominio de producción real.

Endpoints action/204 sin timeout en el cliente

Cualquier @HttpCode(204) sin body (logout,logout-all, forgot-password, reset-password,activate) puede dejar al frontend con el spinner girando para siempre si la request no resuelve — visto en petid-crm/activate por un corte de red puntual, sin ningún timeout que sacara al componente de ese estado.

Se probó un timeout() + fallback puntual en activate.component.ts pero se descartó — no encajaba con el componente, no por estar mal. Falta decidir el patrón (¿timeout por endpoint? ¿interceptor HTTP global?) antes de aplicarlo donde corresponda.

notification-worker sin healthcheck

A diferencia de petid-api/notification-api, no expone HTTP (usa NestFactory.createApplicationContext), así que no hay puerto ni ruta que pinguear. Si el proceso sigue vivo pero pierde la conexión a Redis y no reconecta, los jobs dejan de fluir sin que nada lo señale — restart: unless-stopped solo cubre el caso de proceso muerto.

# worker.Dockerfile (imagen final): instalar redis-tools
RUN apt-get update -y && apt-get install -y openssl redis-tools && rm -rf /var/lib/apt/lists/*

# docker-compose.yml, servicio notification-worker:
healthcheck:
  test: ["CMD-SHELL", "redis-cli -u $REDIS_URL ping | grep -q PONG"]
  interval: 30s
  timeout: 5s
  retries: 3

No confirma que los jobs se procesen de verdad, solo que el worker puede alcanzar Redis — pero es la dependencia sin la que no puede hacer nada.

Throttling por IP, no por usuario

ThrottlerGuard en petid-api es el stock de @nestjs/throttler, sin getTracker() propio — cuenta por IP incluso en rutas autenticadas. En una red compartida (oficina, CGNAT móvil), varios usuarios legítimos comparten cupo; el candidato más probable a un 429 falso-positivo es /auth/refresh, que se dispara automático por sesión.

Plan: ThrottlerGuard custom, trackea por user.id si la request está autenticada, fallback a IP en rutas públicas. Mismo gap en template-api — portar a ambos, no solo a petid-api.