Bricks, CrocoBuilder y Elementor

El plugin trabaja con builders mediante un modelo semantico intermedio. Codex puede analizar una pagina de origen, entender su estructura y crear una nueva pagina en el builder de destino.

El objetivo no es solo copiar JSON interno. El objetivo es que Codex entienda la pagina: que secciones hay, que jerarquia visual tiene, que componentes se repiten, que tokens de diseno usa, que partes dependen de datos dinamicos y que elementos requieren revision manual.

Crear paginas con un builder

Crear una pagina no deberia empezar por "escribe una pagina". El flujo correcto es pedir a Codex que prepare una estructura, la valide contra el builder y solo despues cree un borrador.

Kodavio no es el creativo de la pagina. El MCP sirve para que Codex sepa como crearla en Bricks, Elementor o Gutenberg: que entidad usar, que estructura espera el builder, que campos son seguros, que tokens existen y que confirmaciones hacen falta. El copy, la direccion visual, la jerarquia, los CTAs y el criterio editorial los debe aportar el agente antes de llamar a las abilities de creacion.

kodavio/bricks-create-page y kodavio/elementor-create-page empiezan en dry_run=true y requieren content_model.sections o sections ya pensadas por el agente. kodavio/gutenberg-create-page requiere blocks ya estructurados. Para crear de verdad, repite el payload con dry_run=false y confirm_write=true.

Antes de crear templates o componentes reutilizables, pide kodavio/builder-template-storage-strategy. La regla por defecto es no escribir plantillas generadas en archivos del child theme: Bricks y Elementor deben usar entidades del builder en base de datos, y Gutenberg debe preferir patrones o templates guardados como contenido cuando el sitio lo soporte. Los archivos del tema hijo pertenecen al ciclo de release de Flowkit.

Prompt base:

Crea una pagina nueva con el builder mas adecuado del sitio.

Primero:
- detecta builder activo y capacidades disponibles;
- lee design.md;
- escribe el copy inicial y propone estructura de secciones;
- indica widgets, bloques o elementos que vas a usar;
- prepara un content_model o bloques concretos; no delegues el copy al MCP;
- haz dry_run;
- no escribas nada hasta que confirme.

Bricks

Con Bricks puede trabajar con:

• Paginas.
• Templates.
• Componentes.
• Sistema de diseno.
• Estructura de secciones y elementos.
• Arbol nativo de nodos.
• Formularios nativos con contrato seguro.
• Esquemas de elementos para crear o editar con menos riesgo.

Para trabajos serios en Bricks, pide este orden:

1. Leer la pagina o template.
2. Leer design.md y variables globales si aplica.
3. Si hay formularios, inspeccionar el schema antes de tocar nada.
4. Hacer cambios en nodos concretos o crear una entidad nueva en borrador.
5. Ejecutar health check y editor-open check.

Capacidades Bricks

Cuando pidas una pagina nueva en Bricks, concreta si quieres page, template o component. Si no lo dices, Codex deberia preguntarlo o crear una pagina draft normal.

Novedades de Bricks en la 0.3.2

• Ya no se guardan ids repetidos. Antes, insertar contenido con los elementos en otro orden podía guardar varios con el mismo id y dejar la página sin poder editarse. Ahora Kodavio no escribe un árbol con ids repetidos y, si lo guardado no coincide con lo enviado, devuelve la página a como estaba y te dice qué falló.
• Editar y borrar componentes nativos. Tu agente edita un componente de Bricks con kodavio/bricks-update-native-component y el cambio llega a todas las páginas que lo usan; lo borra con kodavio/bricks-delete-native-component, que se niega mientras alguna página, plantilla u otro componente lo use y te dice cuáles. Las dos pasan por las capacidades de Bricks, con ensayo y confirmación.
• Encender la API de capacidades de Bricks. Bricks 2.4 trae sus propias capacidades, pero vienen apagadas en sus ajustes. Tu agente puede encenderlas con kodavio/bricks-enable-abilities: guarda copia, pide confirmación doble y funcionan desde la siguiente petición. Deshacerlo las apaga otra vez.
• Etiqueta y ancla. Las secciones y grupos conservan su etiqueta (section, ul, figure, blockquote…) y su ancla (id), así que los enlaces dentro de la página siguen funcionando.
• La comprobación de salud lee la página servida y comprueba que la página y su CSS se han cargado. También revisa cabeceras, pies y plantillas de archivo.
• Tras guardar una plantilla con filtros, el manual del agente le indica reindexar los filtros de Bricks (bricks/reindex-filters, una de las capacidades de Bricks que se encienden arriba).

CrocoBuilder

Con CrocoBuilder tu agente puede:

• Crear una página desde un modelo de secciones o desde HTML. Lo de HTML funciona aunque el sitio no tenga Bricks.
• Reescribir una página existente sin cambiarle el id. El estado y el título no cambian: un borrador sigue en borrador.
• Reescribir la cabecera, el pie y las plantillas de entrada y de archivo.
• Cambiar un elemento concreto: sus clases, su etiqueta, su ancla o sus propiedades, sin tocar el resto. Sirve también en plantillas con bucles y paginación, que no conviene reescribir enteras.
• Leer y corregir las condiciones de las plantillas: en qué páginas se aplica cada una.

Antes de cada escritura, el ensayo enseña lo que se va a escribir y cuenta todos los elementos. Al escribir, Kodavio guarda copia del documento, y deshacer lo devuelve exactamente como estaba.

Prompt recomendado:

Rediseña la página 123, que está hecha con CrocoBuilder.

Primero:
- lee la página con builder-analyze-page;
- propón la estructura nueva y el texto;
- haz el ensayo y enséñame el árbol que vas a escribir;
- no escribas hasta que confirme.

Al terminar, comprueba la página servida y dame la referencia para deshacerlo.

Enlaces que envuelven bloques

Kodavio escribe los enlaces de CrocoBuilder como elementos sueltos, sin bloques dentro. Para una tarjeta entera clicable, la tarjeta es un grupo con su título, texto e imagen, y lleva dentro un único enlace que se estira con CSS sobre toda la tarjeta.

Si conviertes HTML con un enlace que envuelve bloques, Kodavio lo resuelve solo así y te devuelve el CSS que hay que añadir.

Conversión con Bricks

• CrocoBuilder se reconoce solo, sin tener que decir el builder.
• La comparación entre la página de origen y la convertida mide el contenido (titulares, textos, enlaces, imágenes…), no la estructura interna, que no significa lo mismo en los dos builders. Ya no salen pérdidas que no existen.
• Los botones de Bricks ya no se pierden al convertir.
• Para lo que no tiene equivalente en el otro builder, kodavio/piece-plan propone una pieza editable con todas sus apariciones.
• CrocoBuilder no guarda el texto alternativo de las imágenes.

Elementor

Elementor puede aparecer en varios modos:

• Legacy con sections y columns.
• Contenedores flexbox.
• Estructuras modernas con elementos mas atomicos cuando el sitio lo soporte.

Cuando pidas trabajo sobre Elementor, indica si quieres conservar el modo actual o preparar una migracion hacia una estructura mas moderna.

El plugin puede leer y operar el arbol nativo de Elementor, crear nodos y validar settings de widgets conocidos. Para Elementor es especialmente importante indicar el modo:

Si migras de legacy a una estructura moderna, pide primero un plan de equivalencias: secciones, columnas, containers, widgets, breakpoints, gaps y estilos heredados.

En migraciones v3 legacy hacia v4_v3, una section con varias columns debe convertirse en un container padre con flex_direction=row en desktop. Cada columna legacy pasa a un container hijo y conserva _inline_size o _column_size como width y flex_basis. Si el origen no trae overrides responsive, tablet y mobile apilan en column por defecto.

Capacidades Elementor

Para paginas nuevas, normalmente conviene pedir flexbox containers salvo que el sitio este claramente en legacy o ya trabaje con atomic v4. Para migraciones a v4, empieza con kodavio/elementor-migrate-mode en dry_run=true, revisa warnings y despues crea un borrador con dry_run=false, confirm_create=true, target_mode=atomic_v4.

Si un borrador flex queda apilado por error, no reescribas toda la pagina. Lee el arbol con kodavio/elementor-tree-read, localiza el container padre y aplica set_container_layout con flex_direction=row, los valores responsive que correspondan y validate_after_write=true.

Para cambios de tipografia en Elementor, evita borrar primitives manualmente. Usa primero kodavio/elementor-clear-typography-overrides con dry_run=true. Si una familia es el unico override del bloque, Kodavio elimina todo el bloque de tipografia; si hay size, weight o line-height, deja font_family como string vacio para heredar el Kit sin provocar CSS invalido.

Gutenberg

Gutenberg se trata como builder nativo. Puede ser destino de conversiones cuando quieres contenido mas portable, editorial o mantenible por WordPress sin depender de builder visual.

Es buen destino para:

• Landings simples.
• Paginas de contenido.
• Patrones reutilizables.
• CTAs y bloques editoriales.
• Contenido que no necesita interacciones complejas del builder.

No es el mejor destino si la pagina depende de widgets avanzados, layouts muy libres, formularios complejos, query loops de builder o efectos visuales muy especificos.

Capacidades Gutenberg

Gutenberg es especialmente util cuando quieres que el resultado sea editable por cualquier usuario de WordPress sin abrir un builder visual.

Conversion entre builders

Empieza siempre con dry_run:

Analiza la pagina con ID 123 y prepara una conversion a Bricks.

Haz primero solo dry_run:
- resume estructura, secciones y widgets detectados;
- indica que se convertira bien;
- indica que partes necesitan revision manual;
- no crees ninguna pagina todavia.

Para conversiones con datos dinamicos, formularios, ecommerce o frameworks de diseno, pide a Codex que cargue primero estos playbooks: builder-conversion-advanced, design-frameworks, dynamic-data-binding y los especificos que apliquen (acf-integration, jetengine-integration, fluent-suite, woocommerce-operations).

Si el plan esta bien:

Crea una nueva pagina en borrador a partir de la conversion anterior.

Condiciones:
- no modifiques la pagina original;
- estado: draft;
- usa el sistema de diseno del sitio;
- despues verifica que la pagina creada se puede recuperar y resume avisos.

Modelo semantico

Las conversiones modernas usan un modelo semantico intermedio. Esto permite analizar una pagina de Bricks, Elementor o Gutenberg y crear una nueva en otro builder sin depender de un conversor directo para cada combinacion.

El modelo deberia recoger:

• estructura de secciones;
• jerarquia de contenidos;
• componentes repetidos;
• estilos relevantes;
• bindings dinamicos;
• comportamiento responsive;
• formularios y acciones;
• fidelidad esperada;
• partes que necesitan revision manual.

Como funciona una conversion

Tambien existen conversores directos entre Bricks y Elementor. Usalos cuando el caso es simple o cuando quieres compatibilidad con el flujo anterior. Para resultados de mayor calidad, pide el flujo semantico.

Conversiones soportadas y ampliables

El sistema esta preparado para que cada builder aporte dos piezas: lectura hacia el modelo semantico y escritura desde el modelo semantico. Con esa arquitectura se pueden soportar nuevas combinaciones sin crear parches aislados.

Widgets, elementos y terceros

Bricks y Elementor tienen ecosistemas enormes. El plugin puede listar esquemas conocidos y descubrir integraciones de terceros, pero no debe escribir configuraciones desconocidas a ciegas.

Flujo recomendado:

1. Listar elementos/widgets disponibles.
2. Leer schema del elemento si existe.
3. Validar settings antes de crear.
4. Usar shortcode o bloque seguro si no hay adapter.
5. Marcar como revision manual lo que no se pueda garantizar.

Si un plugin externo expone abilities propias, Kodavio puede descubrirlas y mapearlas. Para ejecutarlas como parte de un flujo estable hace falta adapter explicito o confirmacion muy controlada.

Como interviene el sistema de diseno

design.md debe leerse antes de crear o convertir. Codex lo usa para:

• elegir tokens existentes en vez de inventar valores;
• mantener tipografias y escalas;
• respetar spacing y breakpoints;
• decidir variantes de botones, cards y CTAs;
• convertir clases o variables de un framework a otro;
• marcar conflictos cuando el builder destino no tiene equivalente directo.

Si una pagina convertida "se parece" pero no respeta la marca, normalmente falta una de estas dos cosas: un design.md limpio o una lectura previa del sistema activo.

Limpieza posterior

No limpies datos antiguos del builder hasta revisar el resultado. La limpieza debe ser una accion separada, manual y con confirmacion.

Antes de limpiar, pide:

• estado de coexistencia;
• que metadata existe de cada builder;
• backups disponibles;
• pagina destino confirmada;
• dry_run de limpieza;
• confirmacion destructiva solo al final.