Gobernar diseños de WordPress con Structure Contracts
Un Structure Contract convierte el diseño Gutenberg previsto por un Blueprint
en un modelo de documento aplicado por el servidor. Permite que un agente se
dirija a campos como hero.title o body.additional sin recibir una ruta de
bloques frágil ni permiso para reconstruir la página.
Los bloqueos del editor mejoran la experiencia, pero no son el límite de seguridad. Composer vuelve a comprobar el contrato en escrituras REST, del editor nativo y de MCP; el marcado de bloques sin procesar no puede eludirlo.
Modelo de propiedad
Cada nodo declarado tiene un propietario:
- La estructura propiedad del Blueprint protege contenedores obligatorios, orden, tipo de bloque y presentación.
- El contenido propiedad de la instancia puede variar por entrada y se edita mediante un ID semántico estable.
- El contenido de slot propiedad del usuario ofrece libertad editorial controlada por tipos permitidos y cardinalidad mínima y máxima.
Esta separación conserva el diseño sin congelar cada palabra.
IDs semánticos estables
Un ID semántico es una política duradera, no un índice de array. Use nombres que describan la función del contenido:
hero
hero.title
body
body.text
body.additional
Cambiar un ID es una migración del contrato. No incluya versión del tema, ID de base de datos, entorno ni posición actual del bloque.
Slots de extensión
Un slot declara su ID semántico y padre, los tipos de bloque hijos permitidos, el mínimo y máximo, si es obligatorio, y el comportamiento de bloqueo y appender.
Composer ofrece inserción, actualización, movimiento y eliminación semánticos. Asigna una identidad estable propiedad del usuario a cada árbol insertado y valida todo el documento después de cada cambio. Un fallo de cardinalidad o de allowlist es atómico: el borrador no se guarda parcialmente.
Patrones estructurales sincronizados
Guarde la estructura reutilizable en un patrón sincronizado wp_block
publicado. La entrada conserva una referencia nativa core/block bloqueada en
lugar de copiar el árbol.
Use Pattern Overrides nativos para los campos de instancia. Composer guarda
los hijos de los slots en la instancia del patrón de la entrada, no en el
wp_block compartido. Editar una entrada no puede modificar todas las páginas.
El Site Contract identifica el patrón gobernado, su registro wp_block local,
versión, enlaces de overrides y Structure Contract compatible. Theme &
providers solo indica que falta una fuente cuando ese tipo de fuente es
relevante y realmente no está disponible.
Creación nativa en WordPress
El Site Contract puede definir Add New por tipo de entrada:
off: la creación nativa queda sin gestionar;optional: un administrador puede elegir un Blueprint compatible;required: el documento debe iniciarse con el Blueprint predeterminado.
El documento nativo recibe el mismo Blueprint, patrones sincronizados, Structure Contract, baseline, idioma y protección de guardado en servidor. Esto no lo convierte en propiedad del agente.
Evolución y reconciliación de patrones
Una revisión compatible puede cambiar la presentación protegida si mantiene todos los campos semánticos y slots obligatorios. Los Pattern Overrides y los hijos de slots del usuario permanecen ligados a su instancia.
Si una revisión elimina o cambia un enlace obligatorio, Composer informa de un estado explícito inválido o que requiere reconciliación. No reescribe entradas ni descarta contenido silenciosamente.
Para un cambio versionado:
- clone el Config Set activo;
- registre el Structure Contract y Blueprint sucesores;
- defina una migración exacta de origen a destino;
- previsualice sin escribir;
- clasifique elementos automáticos y que requieren revisión;
- cree propuestas vinculadas a la revisión;
- haga que una persona fusione las propuestas aceptadas.
La planificación masiva está limitada y la creación de propuestas es explícita. Una migración nunca se convierte en publicación masiva automática.
Responsabilidades del tema y los providers
El tema posee plantillas, patrones sincronizados, marcado, estilos y tokens de
theme.json. Un provider posee el esquema y materializer de sus componentes.
Composer posee contrato semántico, validación, mutación gobernada, estado de
reconciliación, propuestas y auditoría.
Las secciones de Knowledge Base de AI Kit pueden ser contenedores semánticos de descendientes gobernados de Gutenberg o Agent Canvas. Feature y Doc Search mantienen su validación más estricta de hijos.
Lista de aceptación
- Cada ID semántico es estable y único.
- Cada campo o slot obligatorio se resuelve una vez tras expandir el patrón.
- Cada bloque permitido está registrado y validado.
- Los límites de slot reflejan la libertad editorial prevista.
- Pattern Overrides cubre todos los campos de instancia.
- El contenido de slots de instancia no cambia el
wp_blockcompartido. - Add New, edición MCP, preview, propuestas y reconciliación se prueban con el tema activo.
- Los cambios publicados siguen basados en propuestas y aprobación humana.
Continúe con Configuración y ciclo de vida, Integración del tema y Acceso MCP y OAuth.