Qué tan reversible es el modelo de menús

Evaluación de cuánto costaría cambiar de opinión, más adelante, sobre cada decisión del modelo propuesto en RF-007. La pregunta se hace ahora, antes de escribir código, que es cuando cambiar de opinión sale gratis.

Alcance. Se mide la reversibilidad de cada decisión por separado, no del modelo como bloque, porque no se deshacen igual. Los costos son relativos —trivial, bajo, medio, alto— y no horas: dependen de cuánto contenido haya cargado cuando se quiera cambiar.

Respuesta corta

El modelo es barato de cambiar en casi todo, menos en una cosa: la sincronización de categorías. El resto son pocas decenas de documentos y una migración de datos.

Eso sugiere partirlo en dos etapas y decidirlas por separado. La primera —menús reutilizables con entradas cargadas a mano— reemplaza al menú actual, entrega el panel desplegable y se puede deshacer casi por completo. La segunda —sincronizar el catálogo y las entradas de categoría— es la que deja huella: infraestructura que hay que operar y contenido que se acumula donde antes no existía.

Lo que hace barato cambiar

Cuatro propiedades del modelo son las que sostienen la reversibilidad. Conviene saber cuáles son, porque son también las que se pueden perder sin darse cuenta si alguien las viola al implementar.

1. El volumen es chico. Un menú completo son decenas de documentos, no millones de filas. Cualquier restructuración es un guion que corre en segundos. Es la razón principal por la que casi todo es barato.
2. Se guardan descriptores, no resultados. El CMS anota qué categoría y cuántos niveles, y nunca guarda las categorías hijas resueltas. Cambiar cómo se expande es un cambio del storefront, sin tocar un solo dato.
3. Los campos del catálogo y los de presentación están separados. No es prolijidad: es la garantía de que el enriquecimiento se puede llevar a otro lado si la sincronización se abandona.
4. El contrato con el storefront es la API pública. El storefront lee un árbol y lo dibuja. Ni el CMS sabe cómo se ve, ni el storefront sabe cómo se cargó.

Costo de cambiar de opinión, decisión por decisión

Si más adelante queremos…	Costo	Por qué
Sumar o sacar un campo de la entrada	Trivial	Migración de esquema y nada más
Mover la orientación del menú al lugar donde se usa	Bajo	Se agrega el campo en el lugar de uso y cae de vuelta al del menú si está vacío. No hay que decidirlo ahora
Cambiar el tope de niveles	Trivial	Es una validación. Bajarlo oculta contenido, no lo borra
Dejar de usar "incluir" y que todo se abra	Bajo	Son pocas entradas; un guion las convierte
Cambiar cómo se ve el menú en la tienda	Bajo	No toca datos. Es trabajo de storefront
Cambiar de motor de búsqueda o de resolución de filtros	Bajo	El menú guarda un descriptor, no una consulta armada
Volver al menú plano de RF-003	Medio	Aplanar es fácil; se pierde la jerarquía cargada y el trabajo del editor
Cambiar la gramática de destinos (linkConfig)	Alto	Es compartida con banners, sliders y botones. Ya lo era antes de RF-007
Abandonar la sincronización de categorías	Alto	Ver el apartado siguiente

La decisión que sí deja huella

Sincronizar las categorías del catálogo al CMS es la única parte del modelo que no se deshace con un guion. Por tres razones distintas:

Deja infraestructura que hay que operar. Un proceso que corre solo, una credencial, una frecuencia, y algo que avise cuando falla. Eso no se borra: se apaga, y mientras tanto alguien lo mantuvo.

Acumula contenido que antes no existía. El nombre comercial, el ícono y la imagen de cada categoría se cargan una sola vez, pero con doscientas categorías enriquecidas eso es trabajo real que vive únicamente en el CMS. Apagar la sincronización sin más lo pierde.

Crea una segunda copia de algo que ya tiene dueño. Mientras exista, hay dos lugares que dicen cuáles son las categorías, y el menú muestra lo que diga la copia.

La salida de emergencia, y de qué depende

El enriquecimiento se puede exportar y llevar a otro lado —a Medusa mismo, que admite datos adicionales por categoría— siempre que esté guardado contra el identificador del catálogo y separado de los campos que vienen de él. Esa es exactamente la regla que RF-007 ya pide.

Dicho al revés: si al implementar alguien mezcla los campos, o guarda el enriquecimiento contra el identificador interno del CMS, la salida de emergencia se cierra y la decisión pasa de alta a irreversible. Vale la pena que quede como criterio de revisión, no como recomendación.

Lo que hay que sostener para que siga siendo barato

Cinco reglas para la implementación. No son de estilo: cada una sostiene una de las propiedades de más arriba.

1. Nunca guardar el árbol resuelto. Si algún día se guarda la expansión "para que sea más rápido", se pierde la propiedad 2 y el modelo se endurece de golpe.
2. Nunca mezclar campos del catálogo con campos de presentación, ni guardar presentación contra el identificador interno.
3. Que el storefront no sepa de menús. Lee un árbol y lo dibuja. Si aparece lógica que depende de nombres o identificadores concretos de menú, el contrato se rompe y cambiar el modelo pasa a ser un cambio en dos repositorios.
4. Dejar registro de cada sincronización, qué cambió y cuándo. Sin eso no hay forma de deshacer una sincronización mala ni de explicar un menú equivocado.
5. Que el menú no se convierta en base de datos. Si alguien empieza a cargar precios, stock o textos largos en las entradas, deja de ser configuración y pasa a ser contenido crítico, y ahí se acabó la reversibilidad de todo lo demás.

Caso aparte: agregar atributos de estética

Sumar campos que le digan al storefront cómo mostrar algo —un color, un estilo, un tamaño— es trivial en el modelo de datos. Es un campo más en una colección chica, y como los menús ya cargados lo tienen vacío, el storefront cae a su comportamiento de siempre. No hay migración ni riesgo.

El riesgo no está en el modelo, está en qué se guarda en ese campo, y ahí la reversibilidad cambia por completo según la elección:

Lo que guarda el campo	Ejemplo	Reversibilidad
Un nombre del sistema de diseño	destacado, promocion, neutro	Alta. El storefront decide cómo se ve cada nombre; un cambio de marca es una sola edición allá
Un valor literal	#ED0000, 18px	Baja. Se acumula en cada entrada y hay que revisarlas una por una para cambiarlo

La asimetría es lo que decide: pasar de nombres a valores libres es barato, y de valores libres a nombres es caro. Conviene empezar por nombres aunque parezca más restrictivo, porque deja abiertas las dos puertas.

Tres razones más, todas del propio proyecto:

• Es la regla que ya rige. El sistema de diseño del storefront dice, textual, "prohibido el hex literal en componentes: todo color sale de un token", y fija umbrales mínimos de contraste. Un color cargado a mano desde el CMS entra por la ventana a ese sistema.
• Es el patrón que ya usan los campos propios. El botón sobre el banner se ubica con una grilla de nueve posiciones y no con coordenadas libres (RF-001); el enlace tiene apariencias con nombre. Constreñir la elección del editor ya es la manera de hacer las cosas acá.
• Es la misma regla que sostiene todo lo demás. El menú guarda qué categoría, no las hijas resueltas; guarda un descriptor de destino, no una dirección armada. Guardar destacado en vez de #ED0000 es exactamente eso aplicado a la presentación.

Cuándo sí conviene el valor libre

Para campañas con identidad propia y fecha de vencimiento, donde el color es el punto. La forma de darlo sin abrir la puerta del todo es ponerlo en el menú y no en cada entrada, como un tema que se aplica al panel completo. Así una campaña deja un valor suelto, no cuarenta.

El camino natural cuando llegue el momento

El modelo ya tiene destacado como casilla. Convertirla en una lista de estilos con nombre es un cambio compatible hacia atrás: lo que estaba marcado pasa a destacado y lo demás queda vacío. No hace falta decidirlo ahora.

Recomendación

Partirlo en dos etapas y no comprometerse con la segunda hasta que la primera esté en uso.

Etapa	Qué incluye	Reversibilidad
1	Colección menus, entradas propias, abrir e incluir, orientación, el global reducido a dos referencias, y el storefront dibujando	Casi total. Es una colección chica y un componente
2	Sincronización del catálogo, colección de categorías enriquecibles, entradas de categoría y niveles automáticos	Alta al principio, decreciente a medida que se enriquecen categorías

La etapa 1 ya reemplaza a RF-003 y entrega el panel desplegable de varias columnas, que es el objetivo comercial. La etapa 2 agrega que el menú siga al catálogo solo, que es una mejora de gestión, no de lo que ve el comprador.

Separarlas tiene un costo: durante la etapa 1 los rubros se cargan a mano, y eso es justamente lo que la etapa 2 viene a evitar. Es un costo aceptable si la etapa 1 dura poco. Si se estira, el trabajo manual se hace dos veces.

Decisión que esto permite postergar

De las decisiones abiertas de RF-007, M4 —si la orientación vive en el menú o en el lugar donde se lo usa— no hace falta resolverla ahora. Elegir el menú hoy no cierra la otra puerta: el día que haga falta, se agrega el campo en el lugar de uso y, vacío, cae de vuelta al del menú. Las demás conviene cerrarlas antes de empezar.