1
El código tiene tanto Client como Clinic — 6 y 5 ocurrencias respectivamente, apuntándose mutuamente (Clinic.clientId). ¿Son la misma entidad o distintas? ¿Cuál es canónica?
Recomendación: probablemente Clinic es la entidad de dominio (lugar físico/legal) y Client es la relación de facturación. Si no, colapsa a uno solo.
Marta (Engineering Lead): Tienes razón, son distintas. Clinic es la organización de salud que contrata NutriFlow (ej. "Clínica Bienestar Madrid"). Client era un término que usamos al principio para facturación pero en realidad coincide con Clinic. Los usamos como sinónimos por error histórico. Deberíamos usar sólo Clinic en el dominio.
↑ CONTEXT.md
Añadida definición Clinic. Añadido Client como alias a evitar. Eliminado Clinic.clientId — renombrar a clinicId.
⚡ Contradicción detectada en código
src/automations.ts tiene interface Clinic { clientId: string } pero el plan dice que Clinic y Client son lo mismo. Si clientId apunta a otra entidad, necesita un nombre preciso. Si apunta a sí misma, el campo sobra.
2
El modelo tiene User { role: 'dietist' | 'admin' | 'viewer' }. El plan habla indistintamente de "dietista" y "usuario". ¿User es el concepto de autenticación y Dietist el rol de dominio, o son lo mismo?
Recomendación: separar. User = identidad de autenticación (email, contraseña). Dietist = profesional del dominio de negocio. Un User puede tener rol de Dietist, Admin o Viewer.
Marta: Exacto, son distintos. User es la cuenta de acceso. Un Dietist es un User con rol 'dietist' que tiene pacientes asignados. En el motor de automatizaciones, cuando digo "el dietista crea una Automation" me refiero al User con ese rol. Pero en el código de dominio deberíamos hablar de Dietist, no de User.
↑ CONTEXT.md
Añadidos Dietist y User como términos distintos. Relación: una Automation pertenece a un Dietist, no a un User.
3
Account aparece 3 veces en el código sin definición — parece apuntar a Clinic, a User y a algo de facturación. Tu plan menciona "cancelar la suscripción del cliente". ¿Existe un concepto de Account propio, o es simplemente una confusión con Clinic?
Recomendación: eliminar Account del código y glosario si no tiene semántica propia. Si existe una entidad de facturación, nombrarla explícitamente (ej. Subscription).
Marta: Honestamente, Account no debería existir. En algunos contextos lo usé como atajo para referirme a la Clinic, y en otros al modelo de facturación que no llegamos a construir. Lo correcto sería eliminarlo. Si necesitamos una entidad de facturación en el futuro, la llamaremos Subscription.
⚑ Ambigüedad resuelta
Account eliminado del glosario y marcado como término prohibido. Añadida nota: si emerge entidad de facturación, usar Subscription.
4
El plan tiene tres funciones cancel: cancelAutomation, cancelTrigger y cancelSubscription. Tu glosario define Automation.status como 'active' | 'paused' | 'cancelled'. ¿"Cancelar una Automation" es lo mismo que "pausar"? ¿O son irreversibles vs reversibles?
Recomendación: precisar. Pause = reversible (el dietista puede reactivar). Delete = eliminación permanente. Eliminar el término "cancel" del dominio de Automation para evitar confusión con "cancel subscription".
Marta: Buena captura. "Cancelar una Automation" en nuestro contexto significa desactivarla temporalmente — o sea, lo que tú llamas Pause. Si el dietista quiere eliminarla para siempre, lo llamamos Delete. "Cancelar la suscripción" es un concepto de billing completamente distinto. El status: 'cancelled' en el código es incorrecto — debería ser 'paused'.
⚡ Contradicción
Código usa status: 'cancelled' pero el dominio usa 'paused'. Corregir en automations.ts. Actualizado CONTEXT.md: "Pause" vs "Delete" son los únicos estados de ciclo de vida de Automation.
5
El plan propone un "cron interno" (polling Postgres cada 30s). El plan menciona que se descartó Temporal.io "por curva de aprendizaje alta" pero esta decisión no tiene ADR. Si dentro de 3 meses el equipo crece y alguien propone Temporal.io, ¿tenéis el razonamiento escrito?
Esta decisión cumple los 3 criterios ADR: es difícil de revertir (cambio de motor de ejecución), sorprendente sin contexto (¿por qué no Temporal siendo el estándar?), y resultado de un trade-off real. Merece ADR.
Marta: No, sólo está en Notion y en una conversación de Slack de hace dos meses. Tienes razón — si el equipo crece alguien lo va a repreguntar. Además hay otra decisión relacionada: usamos Redis Streams en lugar de una cola dedicada (RabbitMQ/SQS) también por simplicidad operativa. Esa tampoco está documentada.
⊞ ADR-0001 creado
Polling Postgres vs Temporal.io — decisión registrada con contexto y alternativas consideradas.
6
Escenario concreto: un Dietist tiene 200 pacientes. Define una Automation "si adherencia < 70% durante 7 días, escalar a la Clinic". ¿Cuántas instancias de esta Automation existen? ¿Una por Dietist, una por Patient, o una global por Clinic?
Importante para el modelo de datos. Si hay una Automation por Dietist que se evalúa sobre múltiples Patients, necesitáis diferenciar entre la definición de la regla y su ejecución por Patient. Propongo: AutomationRun = instancia de ejecución.
Marta: Nunca lo habíamos pensado así. La Automation es una definición global del Dietist — se aplica a todos sus Patients o a un segmento filtrado. Cada vez que se evalúa y dispara para un Patient específico, eso es una ejecución separada. El concepto de "instancia de ejecución" no lo teníamos. Lo llamaríamos AutomationRun, tiene sentido.
↑ CONTEXT.md
Nuevo término AutomationRun añadido: instancia de ejecución de una Automation sobre un Patient específico.