> ## Documentation Index
> Fetch the complete documentation index at: https://internal.softcrum.com/llms.txt
> Use this file to discover all available pages before exploring further.

# ADR-025 — Release 1 es toda la suite; las fases son orden de trabajo, no versiones

> Lo especificado hasta hoy se entrega como un solo release, compuesto por cinco entregas de módulo que se prueban por separado. F1a, F1b y F2 dejan de ser versiones y pasan a ser el orden en que se construye dentro de ese release.

Estado: Aceptado · Fecha: 2026-08-18 · Afecta: los cinco PRD, `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 a `2026.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.

Un spec marcado `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:

| Entrega              | Módulo      | Depende de    |
| -------------------- | ----------- | ------------- |
| `R1 · Identity`      | `identity`  | nada          |
| `R1 · Customer Core` | `core`      | Identity      |
| `R1 · Loyalty`       | `loyalty`   | Customer Core |
| `R1 · Messaging`     | `messaging` | Customer Core |
| `R1 · CRM`           | `crm`       | Customer Core |

Cada entrega tiene su página en [Releases](/releases/overview) 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 → { Loyalty, Messaging, CRM }**. 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 fechas `2027.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](/releases/overview) 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 `naming` se extiende a `release`: un endpoint o una tabla que declare una entrega que
  no existe es un error.

## Changelog

| Versión | Fecha      | Cambio           | Por qué                                                                                                       | Autor                  |
| ------- | ---------- | ---------------- | ------------------------------------------------------------------------------------------------------------- | ---------------------- |
| 1.0.0   | 2026-08-18 | Decisión inicial | Las fases se estaban usando como versiones entregables y dos de las tres fechas no salían de ninguna decisión | daniel + claude-opus-5 |