modules/*/api.md, DEC-D7 · Refs: ADR-024
Contexto
Las specs heredaron las fases F1a / F1b / F2 del PRD de fidelización y, sin que nadie lo decidiera, esas fases empezaron a usarse como si fueran versiones entregables. La página de APIs de Loyalty llegó a mapearlas a2026.11, 2027.1 y 2027.4.
Eso tiene tres problemas.
Un cliente no puede probar una fase. F1a de Loyalty entrega el libro de puntos pero no los
niveles; F1a de Messaging entrega el envío pero no las campañas. Un design partner que recibe eso no
tiene un producto, tiene un conjunto de piezas que no cierran un caso de uso completo.
Las fases no están alineadas entre módulos. F1b de CRM y F1b de Loyalty no dependen una de la
otra ni comparten fecha. Tratarlas como una misma versión inventa una sincronización que no existe.
Las fechas de F1b y F2 eran objetivos inventados. 2027.1 y 2027.4 no salieron de ninguna
decisión: las escribí para llenar una columna. Una fecha sin decisión detrás es peor que ninguna,
porque alguien la va a planificar.
Lo que sí existe es un hito real y comprometido: G1-Engage, 2026-11-01, un design partner
operando CRM + Fidelización end to end.
Decisión
1. Release 1 es todo lo especificado hasta hoy
Release 1 = 2026.11 e incluye los cinco módulos completos: 51 feature specs, 107 tablas,
la superficie de API entera. No es un subconjunto ni un mínimo viable: es la primera entrega grande,
la que un cliente instala y prueba de punta a punta.
Que sea mucho trabajo no lo cambia. Un release parcial obliga a explicarle al cliente qué parte del
producto todavía no existe, y esa conversación cuesta más que construirlo.
2. Las fases son orden de trabajo dentro del release
F1a, F1b y F2 dejan de ser versiones. Pasan a ser exactamente lo que siempre fueron por debajo: el orden en que conviene construir, por dependencia técnica y por riesgo.- F1a — lo que todo lo demás necesita. Se construye primero porque bloquea.
- F1b — lo que completa la propuesta comercial.
- F2 — lo que depende de decisiones aún abiertas o de volumen real.
F2 sigue siendo parte de Release 1. Si al acercarse la fecha algo de F2 no llega,
eso es una decisión de alcance que se toma y se escribe, no un default silencioso.
3. Cada módulo es una entrega tangible
Release 1 se compone de cinco entregas de módulo, y cada una es una unidad que se puede terminar, probar y mostrar por separado:
Cada entrega tiene su página en Releases con su alcance, sus tablas, sus APIs,
sus dependencias y su criterio de “listo”. Esa página es lo que se revisa para declarar una entrega
terminada — no la sensación de que ya está.
La columna Desde de las páginas de API deja de nombrar una versión inventada y pasa a nombrar la
entrega:
R1 · Loyalty. Cuando exista un Release 2, esa columna distinguirá de verdad.
4. El orden se decide por dependencia, no por preferencia
Identity no depende de nadie y todo depende de Core, así que el orden de construcción se cae solo: Identity → Customer Core → . Las tres últimas son independientes entre sí y se pueden construir en paralelo.Consecuencias
+ Un cliente recibe un producto completo, no un subconjunto que hay que explicar. + Desaparecen tres fechas que no tenían decisión detrás. + Cada módulo tiene un criterio de terminado explícito, así que “listo” deja de ser opinión. + El orden de construcción queda derivado de las dependencias reales y no de qué módulo es más entretenido. − Release 1 es grande, y un release grande concentra riesgo. Se mitiga con las cinco entregas: cada una se termina y se prueba sin esperar a las otras. − Los cinco PRD hablan de fases como si fueran entregas y hay que reescribir esa sección en cada uno. − Si algo de F2 no llega a noviembre, la conversación de alcance es más incómoda que si nunca hubiera estado prometido. Es deliberado: preferimos que esa conversación ocurra explícitamente.Alternativas consideradas
Un release por fase — F1a en noviembre, F1b y F2 después. Es lo que estaba pasando de hecho. Perdió porque una fase no es un producto: F1a de Loyalty sin niveles y sin cupones no cierra ningún caso de uso que un design partner pueda ejercitar de verdad. Un release por módulo, sin paraguas. Cinco versiones independientes, cada una con su calendario. Perdió porque el hito comprometido es uno solo y los módulos se prueban juntos: un contacto sin fidelización ni mensajería no demuestra nada. Mantener las fechas2027.1 y 2027.4 como objetivos. Perdió porque no salían de ninguna
decisión. Una fecha inventada en una tabla se convierte en un compromiso en cuanto alguien la lee
sin contexto.
Trabajo de seguimiento
- Sección Releases con la entrega de cada módulo.
modules/*/api.md: la columna Desde nombra la entrega, no una versión inventada.- Los cinco PRD: la sección de fases se reescribe como orden de trabajo dentro de Release 1.
- El validador
namingse extiende arelease: un endpoint o una tabla que declare una entrega que no existe es un error.