RF-007 — Menús reutilizables y navegación desplegable

Estado	En implementación — historia #299. La sincronización de categorías queda para una etapa posterior
Tipo	Colecciones propias
Extiende a	RF-003 · Menú de navegación. No lo reemplaza: la barra y sus ítems quedan como están
Plan	Plan de implementación · contrato: Menús para el storefront
Reversibilidad	Evaluada en este análisis: barata salvo la sincronización
Depende de	RF-000 · destinos — RF-005 · medios — RF-006

Requisito

Administrar los menús del sitio como piezas independientes y reutilizables, configurables por separado y con sus propias entradas, que después se asignan donde hagan falta: a la barra de navegación, al pie, o dentro de otro menú.

Un menú se relaciona con otro de dos maneras distintas, y las dos hacen falta:

• Abriéndolo. La entrada despliega el otro menú en un panel al pasar el mouse. Es lo que produce la navegación de varios niveles.
• Incluyéndolo. El otro menú se dibuja adentro del panel como una sección con su propio título. Es lo que produce los paneles de varias columnas, donde cada columna es una lista titulada.

Permitir además que una entrada, en lugar de escribirse a mano, se apoye en una categoría del catálogo, y que un parámetro defina cuántos niveles de esa categoría se traen solos. Para que esas categorías se puedan elegir y enriquecer desde el panel, se sincronizan al CMS en una colección propia, donde reciben ícono e imagen sin dejar de seguir al catálogo.

Permitir por último elegir cómo se acomodan las entradas de cada menú, en lista vertical o en fila horizontal, porque una misma estructura se dibuja de las dos maneras según el lugar.

Hoy la barra se carga como una lista de accesos sueltos, todos del mismo nivel y sin contenido debajo (RF-003). Esa lista se conserva: lo que se agrega es que cualquiera de sus ítems pueda desplegar un menú.

Solución adoptada

Modelar el menú con el mismo patrón que ya usan los sliders (RF-002): una colección propia donde cada documento es un menú con nombre, identificador y sus entradas cargadas adentro; y una referencia desde donde se lo quiera usar, en lugar de contenido embebido. Quitar la referencia saca el menú de ese lugar sin destruirlo, y el mismo menú puede estar referenciado desde más de un lugar a la vez.

Las categorías del catálogo se copian al CMS en una colección propia y separada de la del blog. La copia es de una sola mano: el catálogo manda sobre los datos que vienen de él, y el CMS suma encima lo que el catálogo no tiene, que es la presentación.

El panel de varias columnas, pieza por pieza

El ejemplo de referencia es un panel de auriculares con cinco columnas tituladas y una pieza gráfica al costado. Se arma así:

flowchart TD
    E["Entrada: Auriculares y Parlantes<br/>en el menú de electrónica"] -->|abre| P[("Menú · auriculares-y-parlantes<br/>orientación: horizontal<br/>imagen: pieza gráfica del costado")]
    P -->|incluye| C1[("Menú · ver-todo<br/>vertical")]
    P -->|incluye| C2[("Menú · auriculares-por-tipo<br/>vertical")]
    P -->|incluye| C3[("Menú · auriculares-por-marca<br/>vertical")]
    P -->|incluye| C4[("Menú · parlantes-bluetooth<br/>vertical")]

El menú del panel está en horizontal, así que los menús que incluye quedan uno al lado del otro. Cada uno de esos está en vertical, así que sus entradas bajan en lista. El título de cada columna es el nombre del menú incluido.

Modelo de datos

Los nombres de campo van en inglés y las etiquetas del panel en español, por ADR-0007. Quien carga contenido ve las etiquetas, no estos nombres.

Colección catalog-categories — categorías del catálogo

Los rubros de venta con los que se arman los menús, en una colección separada de categories, que clasifica entradas del blog y no se toca. Por ahora se cargan a mano; más adelante los va a traer la sincronización.

Campo	Tipo	Regla
name	texto, requerido	Nombre de la categoría
slug	texto único	Dirección amigable. Se genera del nombre y se puede editar
parent	relación → sí misma	La categoría de la que cuelga. Vacío en las de primer nivel
image	upload → media	Imagen de la categoría, heredada por los menús donde aparezca
icon	select del juego cerrado	Oculto en el panel mientras se decide M6. La columna se conserva para no migrar dos veces
children	campo de unión sobre parent	Derivado, no se guarda. Hace que la API entregue el árbol anidado en una sola consulta. Orden alfabético, sin tope de hijas

Arranca con lo mínimo que hace falta para armar un menú (2026-09-17). Los campos que pida la sincronización —identificador en el catálogo, marca de activa, fecha de la última corrida— se agregan cuando esa etapa se haga: sumar un campo es aditivo y barato, y hoy no sabemos cuáles va a necesitar exactamente.

Colección menus

Campo	Tipo	Regla
name	texto	Requerido. Es el título visible cuando el menú se incluye como sección
description	textarea	Uso interno. Para qué sirve y dónde se usa
orientation	radio	vertical por defecto, u horizontal. Cómo se acomodan sus entradas
submenuMode	radio	open por defecto, o include. Cómo se enganchan los submenús de todas sus entradas
link	grupo linkConfig	Destino propio del menú. Opcional. Hace clickeable su nombre
image + imageLink	upload → media y grupo linkConfig	Pieza gráfica del panel con su destino. Opcional
items	arreglo ordenado	Las líneas del menú. Se ordenan por arrastre

Cada entrada del arreglo

Campo	Tipo	Regla
type	radio	Requerido. own o category. Solo se pide cuando el menú abre sus submenús
name	texto	Requerido en las propias. En las de categoría reemplaza al nombre de la categoría, si se carga
link	grupo linkConfig	Solo en las propias
category	relación → catalog-categories	Solo en las de categoría. Requerido
autoMaxLevels	número, opcional	Solo en las de categoría. Profundidad máxima que se trae del catálogo. Vacío trae todos los niveles; 0 no trae ninguno
autoPresentation	radio	Solo en las de categoría que traen algo. Si lo traído se abre (open) o se incluye (include)
autoOrientation	radio	Solo en las de categoría que traen algo. Orientación del panel generado
submenu	relación → menus	El menú que cuelga de esta entrada. Solo en las propias: una de categoría arma su submenú con las subcategorías. Se abre o se incluye según el submenuMode del menú que la contiene
icon	select	Ícono a la izquierda del texto
badgeText	texto	Distintivo corto: NUEVO, 15% OFF. Oculto en el panel: viene heredado de RF-003 y no se decidió todavía si el menú nuevo lo usa. La columna se conserva para no perder los valores al migrar el menú plano
highlight	checkbox	Resalta la entrada
isVisible	checkbox	Verdadero por defecto. Oculta la entrada sin borrarla

Global main-navigation

No se reemplaza: se extiende. Sigue siendo la barra de navegación tal como está definida en RF-003, con sus ítems, sus destinos y sus etiquetas. Lo único que se le agrega es que un ítem pueda además desplegar un menú.

Campo	Tipo	Regla
items[].type	radio	Nuevo. direct o menu. Decide qué campos se piden en esa fila
items[].menu	relación → menus	Nuevo. Solo en las de tipo menu. Requerido ahí

El tipo condiciona la fila, no se suman campos sueltos. Un ítem direct es el de siempre: texto, destino, etiqueta, resaltado y visibilidad. Un ítem menu pide solo el menú: su texto sale del name de ese menú y su destino, del link propio de ese menú.

Las filas cargadas antes de este cambio no tienen type. Cualquier valor que no sea menu se trata como acceso directo, que es lo que eran, y la migración las completa.

label y destinationType dejan de ser obligatorios en el esquema y pasan a exigirse solo en los ítems de tipo direct: un campo oculto por condición sigue validando.

Los campos que no corresponden al TIPO de la entrada se ocultan en la lectura pública, no se borran. La orientación y el modo del menú no intervienen ni en el enmascarado ni en el formulario. Un valor por defecto se aplica aunque el campo esté oculto en el panel, así que sin esto un ítem de tipo menu se leería con destinationType: 'filter', como si tuviera un filtro configurado.

Se enmascara al leer y nunca al guardar. Cambiar el tipo de un ítem, o el modo de un menú, no puede costarle al editor el trabajo ya cargado: tiene que poder probar una configuración y volver atrás sin perder nada. El panel y la API local reciben los datos completos; solo la lectura pública, que es la del storefront, viene enmascarada.

El pie de página no entra acá: tiene su propio global footer.

Reglas de negocio

De la sincronización de categorías

• Sincronizar en una sola dirección: del catálogo al CMS. El CMS nunca escribe al catálogo.
• Mantener los campos que vienen del catálogo como solo lectura en el panel, para que una sincronización posterior no borre trabajo del editor.
• No pisar nunca los campos de presentación, que son lo que el CMS aporta y el catálogo no tiene.
• Marcar como inactiva la categoría que desaparece del catálogo, en lugar de borrarla: así no se pierde su presentación ni se rompen los menús que la usaban. Pide un campo que hoy no existe: se agrega con la sincronización.
• Dar de alta sola la categoría nueva, sin presentación cargada, y mostrarla como pendiente de enriquecer.
• Permitir lanzar la sincronización a mano además de por su frecuencia habitual, para no esperar cuando se acaba de cargar un rubro.
• Dejar registro de cuándo corrió y qué cambió, porque es la única forma de explicar un menú que no muestra lo que el catálogo tiene.

Del menú y su reutilización

• Exponer las colecciones con lectura pública: es contrato con el storefront.
• Permitir que un mismo menú esté referenciado desde varios lugares, y editarlo en uno solo.
• Distinguir abrir de incluir: abrir despliega el menú en un panel nuevo al pasar el mouse; incluir lo dibuja adentro del panel actual como sección con su nombre por título.
• Decidir eso por menú y no por entrada. Un panel que mezcla las dos formas no se entiende mirándolo: el comprador no distingue qué está a la vista de qué aparece al pasar el mouse.
• Mantener el formulario de la entrada igual, cualquiera sea la configuración del menú. Los campos que se piden dependen del tipo de la entrada, que es una elección del editor, y nunca de la orientación ni del modo de enganche, que son opciones de presentación.
• Tomar el título de una sección incluida del nombre del menú incluido. El texto de la entrada queda guardado pero no se dibuja en ese caso.
• No contar las inclusiones contra el tope de niveles: incluir no abre un panel nuevo, dibuja en el mismo.
• Admitir hasta tres niveles abiertos, se hayan armado a mano o traído del catálogo.
• Impedir que un menú se referencie a sí mismo, directa o indirectamente, tanto abriéndolo como incluyéndolo.
• Impedir el borrado de un menú referenciado desde otro lugar —por otro menú o por la navegación—, nombrando quién lo usa, en vez de dejar la referencia apuntando a la nada. El panel no admite una advertencia que se pueda ignorar: o deja pasar o corta.
• Permitir que una entrada tenga destino propio y submenú al mismo tiempo: son independientes.
• Ofrecer como "Ver todo" del panel el destino propio del menú si lo tiene, y si no el de la entrada que lo abrió.
• Tratar una entrada sin submenú como acceso directo, igual que los accesos de hoy.
• Ocultar una entrada con isVisible en lugar de eliminarla.
• No borrar nunca configuración del editor como efecto de cambiar una opción de presentación. Cambiar la orientación, el modo de enganche o el tipo de una entrada solo cambia qué se muestra, nunca qué está guardado.
• Mantener ocultos en el panel, pero presentes en el esquema, los campos cuya forma definitiva todavía se está decidiendo: hoy el ícono (M6) y la etiqueta. Se conservan para no migrar dos veces y para no perder los valores que traiga la migración del menú plano.

De las entradas de categoría

• Tomar el nombre y el destino de la categoría, y permitir reemplazar el texto sin desarmar el vínculo.
• Resolver las categorías hijas al momento de dibujar el menú, de modo que una categoría nueva aparezca sola y una inactiva desaparezca sola.
• Heredar la imagen cargada en la categoría, para no volver a cargarla en cada menú donde aparezca. El ícono hará lo mismo cuando se resuelva M6.
• Traer por defecto todos los niveles que tenga el rubro en el catálogo, y respetar el número cargado como tope cuando lo haya: si el rubro tiene menos niveles se trae lo que haya, y si tiene más se corta ahí.
• Recortar igual lo que exceda el tope de niveles abiertos. El número de la entrada limita cuánto se trae del catálogo; el tope general limita cuántos paneles atraviesa el comprador. Manda el más chico de los dos. Con la presentación en modo incluir el tope general no interviene, porque incluir no abre paneles.
• No dibujar en la tienda la entrada cuya categoría quedó inactiva, y señalarla en el panel para que el editor la corrija. Pide el mismo campo pendiente de la sincronización.

Qué hereda lo que se trae solo

Una entrada de categoría con niveles automáticos genera un submenú que nadie cargó, así que no hay un menú de dónde tomar sus ajustes. De ahí estas reglas:

• Tomar de cada categoría su nombre, su destino, su ícono y su imagen. Son los que se cargaron una vez al enriquecerla, y valen en todos los menús donde aparezca.
• Tomar de la entrada cómo se presenta lo generado, porque es lo único cargado a mano que hay: si las categorías hijas se abren o se incluyen, y en qué orientación.
• Convertir con dos niveles o más las categorías hijas en títulos de sección y las nietas en las líneas de cada sección. Es el panel de varias columnas armado solo.
• Dejar las hijas como líneas simples con un solo nivel, sin sección ni título.
• Respetar la misma regla de orientación que un menú cargado a mano, incluido por dónde sale el panel siguiente.

De la orientación

• Aplicar la orientación a las entradas propias del menú: en vertical bajan en lista, en horizontal se acomodan en fila.
• Sacar el panel siguiente por donde corresponde a la orientación: un menú en horizontal abre sus submenús abajo, ocupando el ancho; uno en vertical los abre al costado. Un panel que sale al costado de una fila horizontal queda fuera de la pantalla.
• Acomodar en columnas los menús incluidos cuando el menú que los incluye está en horizontal, y uno debajo del otro cuando está en vertical.
• Reservar la combinación de vertical con menús incluidos para el pie de página y para el celular. En un panel ancho apila todo en una columna larguísima que obliga a recortar con barra de desplazamiento; ahí corresponde horizontal.
• Acotar la altura del panel y recortar con desplazamiento cuando el contenido la supera, en lugar de estirar el panel fuera de la pantalla.
• Volver a lista vertical en pantalla angosta, cualquiera sea la orientación cargada: en el celular no hay fila que entre.

Cómo se comporta cada configuración

Doce sentencias que describen qué se dibuja según cómo esté cargado. Valen tanto para lo que se carga a mano como para lo que se trae del catálogo, y son la base de los recortes que hace el storefront al armar el menú.

De la orientación

1. La orientación de un menú decide cómo se acomodan sus propias entradas: en vertical bajan en lista, en horizontal van en fila.
2. La orientación decide también por dónde sale el panel siguiente: un menú horizontal lo abre abajo, ocupando el ancho; uno vertical lo abre al costado.

Del enganche

1. Un menú que abre pone cada submenú en un panel nuevo, que aparece al pasar el mouse, y suma un panel.
2. Un menú que incluye dibuja cada submenú dentro de su propio panel, como sección titulada con el nombre de ese submenú, y no suma panel.

De la inclusión, que es donde están los límites

1. Un menú incluido se dibuja siempre como lista vertical, sin importar su propia orientación. Su orientación vuelve a regir en otro lugar donde se lo abra en vez de incluirlo.
2. La inclusión es terminal. Las entradas de un menú incluido no pueden abrir ni incluir nada: no hay panel donde dibujarlo ni interacción que lo dispare.
3. Por lo tanto, un menú que incluye muestra exactamente dos niveles: sus entradas como títulos de sección y las entradas de cada una como líneas. Lo que cuelgue más abajo no se puede mostrar de ninguna manera.
4. Un menú que abre sí puede encadenar: cada salto agrega un panel, hasta el tope de tres.

De lo que se trae del catálogo

1. Los niveles traídos del catálogo siguen exactamente las mismas reglas que los cargados a mano.
2. Con presentación incluida, la profundidad efectiva es dos como mucho, cualquiera sea el número cargado: las categorías hijas son los títulos y las nietas las líneas. Lo que esté más abajo se descarta.
3. Con presentación abierta, la profundidad efectiva es la menor entre el número cargado y los paneles que queden libres bajo el tope.

De la barra de navegación

1. La barra de navegación no es un menú: es la lista de ítems del global, y sigue funcionando como hasta ahora. Un ítem de tipo menú lo abre al pasar el mouse; la barra nunca incluye, porque es una fila horizontal y no tiene panel propio donde dibujar.
2. El menú que despliega un ítem de la barra es el primer panel. A partir de ahí rigen las sentencias anteriores.
3. Un ítem de tipo menú no tiene texto ni destino propios: los toma del menú. Así no hay dos lugares donde cargar lo mismo.

Del destino propio del menú

1. Un menú puede tener destino propio, igual que una entrada. Se usa donde se muestra su nombre: como título de sección cuando se lo incluye, y como "Ver todo" de su panel cuando se lo abre.
2. El destino de la entrada y el del menú no compiten. El de la entrada gobierna la línea que se pulsa en el menú de arriba; el del menú gobierna el encabezado de su propia sección o panel. Un menú sin destino propio muestra su nombre sin enlace.

Del recorte

1. El recorte se hace al armar el menú, no al cargarlo. El editor puede pedir más profundidad de la que se puede mostrar, y el sistema dibuja lo que entra. El catálogo cambia solo, así que bloquear al guardar dejaría menús rotos sin que nadie los toque.

Comportamiento esperado en el storefront

• Pulsar una entrada lleva a su destino. Pasar el mouse por encima abre su submenú, si tiene.
• Mantener el panel abierto mientras el puntero viaja desde la entrada hacia adentro del panel.
• En pantalla táctil no hay "pasar el mouse": el primer toque sobre una entrada con submenú abre el panel sin navegar, y para ir a su destino está la opción "Ver todo".
• Recorrer y abrir todo el menú con el teclado, y cerrarlo con la tecla de escape.
• Mostrar el mismo menú en el lateral del celular, recorriéndolo por columnas.
• Reconstruir la navegación completa sin una llamada por nivel ni por categoría: las subcategorías viajan anidadas dentro de la categoría de cada entrada.

Criterios de aceptación

#	Criterio
1	Recuperar la navegación completa por API, sin autenticación
2	Configurar un menú por separado y asignarlo a la barra desde el global
3	Asignar a una entrada un submenú y comprobar que se despliega al pasar el mouse
4	Encadenar tres niveles abiertos y verlos anidados; rechazar el cuarto
5	Referenciar el mismo menú desde dos lugares, editarlo una vez y ver el cambio en ambos
6	Quitar un menú de la barra y comprobar que sigue existiendo para volver a asignarlo
7	Rechazar una cadena que vuelva sobre sí misma, tanto abriendo como incluyendo
8	Reordenar las entradas por arrastre y ver el nuevo orden en la API
9	Incluir cuatro menús en uno horizontal y ver el panel en cuatro columnas tituladas
10	Cambiar ese menú a vertical y ver las mismas secciones una debajo de otra
11	Comprobar que las inclusiones no consumen niveles del tope
12	Ver el panel de varias columnas convertido en lista vertical en pantalla angosta
13	Correr la sincronización y ver las categorías del catálogo en el CMS con su jerarquía
14	Cargar ícono e imagen a una categoría, volver a sincronizar y comprobar que no se pisaron
15	Renombrar una categoría en el catálogo, sincronizar y ver el nombre nuevo en el menú
16	Dar de baja una categoría en el catálogo, sincronizar y verla inactiva sin perder su presentación
17	Crear una entrada de categoría sin tope y ver toda la rama del catálogo desplegada
18	Agregar una categoría hija en el catálogo y verla aparecer en el menú tras sincronizar
19	Comprobar que la entrada de categoría hereda el ícono cargado en la categoría
20	Combinar en un mismo menú entradas propias, de categoría y menús incluidos
21	Abrir el submenú de un menú horizontal y verlo aparecer abajo, no al costado
22	Abrir el submenú de un menú vertical y verlo aparecer al costado
23	Comprobar que un panel vertical con secciones incluidas se acota y se desplaza, sin estirarse fuera de pantalla
24	Pedir dos niveles con presentación incluida y ver el panel de varias columnas armado solo
25	Cambiar la presentación de esa misma entrada a abierta y ver las hijas convertidas en submenús
26	Recorrer y abrir la navegación completa solo con el teclado

Convivencia con RF-003

No hay migración de datos: los ítems de la barra se quedan donde están, con sus destinos y sus etiquetas. El cambio es aditivo.

Lo que sí sigue pendiente de RF-005 es el desajuste de nombres —tag contra product_tag, custom contra index— que el global arrastra desde antes de este requisito. Se corrige por separado, porque no es parte de este cambio.

El campo categories del ítem, ya marcado obsoleto en RF-003, sigue oculto y sin uso.

Decisiones cerradas

M1 · Dónde viven las categorías del catálogo

Las categorías del catálogo van en una colección propia, catalog-categories, separada de categories (2026-09-17). La colección categories es la del blog: la usan las entradas, el bloque de archivo y el complemento de búsqueda. Mezclar las dos obligaría a filtrar en esos tres consumidores y dejaría las dos jerarquías entreveradas en el mismo árbol anidado.

El nombre evita product-categories a propósito, porque el catálogo de Medusa expone /store/product-categories y dos cosas con el mismo nombre en servidores distintos confunden a quien consume las dos.

Como consecuencia, a categories se le cambia la etiqueta del panel a "Categorías del blog". Es una etiqueta, no un nombre de campo, así que no hay migración.

M9 · Abrir o incluir se decide por menú

Vive en el menú, no en la entrada (2026-09-17). Un solo campo, submenuMode, vale para todas las entradas de ese menú.

Ninguna de las tres referencias mezcla las dos formas dentro de un mismo panel, y un panel mezclado no se entiende mirándolo. Además, pasar más adelante de una decisión por menú a una por entrada es aditivo; al revés hay que juntar valores y decidir por el editor.

Como consecuencia desaparece el tipo de entrada "menú incluido": cada entrada apunta a un menú con submenu, y el menú decide cómo se dibuja. Lo que sí queda en la entrada es autoPresentation, porque describe un panel generado desde el catálogo que no tiene menú propio donde guardar el ajuste.

Decisiones pendientes

Los números no se reusan: M1 ya está cerrada arriba.

#	Decisión	Recomendación
M2	¿Cada cuánto se sincroniza, y se dispara también desde el catálogo al guardar?	Por frecuencia, más un botón para lanzarla a mano. Que el catálogo avise al guardar es mejor pero pide trabajo del otro lado
M3	¿Se pueden excluir categorías hijas puntuales de la expansión automática?	Sí, con una lista de excepciones en la entrada
M4	¿La orientación vive en el menú o en el lugar donde se lo usa?	En el menú, que es lo simple. El costo es que un menú reutilizado se dibuja igual en todos lados
M5	¿Tope de dos o de tres niveles abiertos?	Tres. El ejemplo de referencia usa tres
M6	Íconos: ¿se eligen de una lista de nombres, o se sube un archivo?	Reabierta el 2026-09-17. La lista de nombres quedó implementada pero oculta en el panel: en la práctica elegir por nombre no resultó útil. Se evalúa subir un archivo SVG. Ver el apartado de abajo antes de decidir
M7	Cuando llegue la sincronización, ¿con qué llave empareja una categoría cargada a mano?	A revisar en esa etapa. Hoy la colección no guarda el identificador del catálogo. Sin una llave, la primera corrida va a duplicar todo lo cargado a mano
M8	¿catalog-categories usa el complemento de anidación, como categories?	A revisar. Hoy tiene una relación parent simple, que es lo que pedía el requisito. El complemento agregaría la ruta de ancestros y el bloqueo de ciclos en el panel, y ya está instalado. Es aditivo

Sobre M6, antes de decidir por el archivo

Subir un archivo resuelve lo que la lista de nombres no daba —ver el ícono al elegirlo, y agregar uno sin tocar dos repositorios— pero trae tres cosas que la lista no tenía:

• Un SVG puede traer script adentro. Dibujado en línea en la tienda es una vía de ataque, así que hay que sanearlo al subirlo y limitar quién puede cargarlos.
• La colección de medios manda todo a Cloudflare Images, que genera variantes de distintos anchos y usa la variante grande como dirección por defecto. Eso está pensado para fotos: un SVG por ese camino hay que probarlo antes de darlo por bueno.
• Un archivo con colores fijos adentro ignora el estado y el tema, y nadie se entera hasta que está publicado. Con la lista de nombres eso no podía pasar, porque el color lo ponía la tienda.

Lo que no cambia es la reversibilidad: mientras la entrada guarde una referencia y no el dibujo mismo, pasar de una forma a la otra sigue siendo un guion.

Limitaciones conocidas

• Las categorías quedan duplicadas: el catálogo es el dueño y el CMS guarda una copia. Toda copia puede quedar atrasada, y el menú va a mostrar lo que diga la copia, no el catálogo.
• El orden de las categorías traídas automáticamente es el que tenga el catálogo, no uno editorial. Para ordenarlas a gusto hay que armar el menú a mano.
• Una categoría nueva aparece sola en el menú después de sincronizar. Es la ventaja buscada y también el riesgo: nadie la aprueba antes de que el comprador la vea.
• Sin tope cargado, una rama profunda del catálogo se despliega entera. El valor por defecto trae todos los niveles, así que una rama nueva y larga puede agrandar un panel sin que nadie lo decida. El tope por entrada es la herramienta para acotarlo.
• Un menú reutilizado se ve igual en todos los lugares donde se lo asigna, incluida su orientación. Un menú pensado para un panel ancho no sirve tal cual para el pie.
• La combinación de vertical con secciones incluidas queda disponible aunque no convenga en un panel. El CMS no la impide: la regla está escrita, no forzada.
• No contempla varios idiomas, permisos por menú, ni programar la aparición de una entrada por fecha. Los sliders sí programan por fecha (RF-002); acá queda para después.
• La profundidad no está garantizada por la forma del dato, porque surge de cómo se encadenan los menús y de cuántos niveles pida cada entrada. Hay que validarla al guardar y volver a limitarla al dibujar.