Iniciar sesión

Configurar Site Contracts y Blueprints de página

Composer almacena su política de runtime como un Config Set versionado. La jerarquía visible es:

Config Set -> Site Contract -> Blueprints

Cree la configuración desde las reglas más generales hasta las más específicas. Mantenga inmutable el Config Set activo y clónelo cuando necesite cambiar el comportamiento de producción.

1. Crear un Config Set de trabajo​

Abra WP Admin -> SmartCloud -> Agent Composer -> Config sets y cree un conjunto nuevo o clone uno existente.

  • Use Universal Gutenberg para un contrato de página mínimo e independiente del tema, formado por bloques estables del núcleo.
  • Use SmartCloud Recommended para una página portátil más completa con hero, funciones, pasos, preguntas frecuentes opcionales y una acción final.
  • Use Detected Theme Starter para generar un punto de partida local y seguro a partir de un patrón registrado adecuado del tema activo. Composer registra el patrón de origen y las huellas actuales del tema y sus capacidades.
  • Use New para una configuración limpia.
  • Use Clone cuando la configuración activa sea una base útil.
  • Use Import únicamente para un paquete de Composer protegido mediante checksum y en el que confíe.

Los conjuntos creados desde un preset, nuevos, clonados e importados están inactivos. Un preset se copia en un Config Set de trabajo con identificador único; nunca sobrescribe ni activa una configuración. Asigna a cada conjunto una etiqueta estable y descriptiva que explique su finalidad, no una contraseña de entorno, un nombre de cliente ni un ticket interno.

2. Definir el Site Contract​

El Site Contract contiene la política compartida por todos los Blueprints del Config Set. Úselo para restricciones que no deban divergir entre tipos de página, por ejemplo:

  • tipos de entrada de WordPress permitidos;
  • idioma editorial y del operador;
  • pautas de tipografía y sistema visual;
  • reglas de ubicación y pies de medios;
  • expectativas comunes sobre plantillas;
  • restricciones de diseño, como utilizar estilos únicamente de presets del tema;
  • declaraciones de seguridad y políticas independientes de proveedores.

El contrato no es código ejecutable del tema. No incluya en él credenciales, claves de API, callbacks remotos, JavaScript, PHP ni secretos de proveedores. La validación de paquetes portátiles rechaza campos con apariencia de secreto.

3. Añadir un Blueprint para cada tipo de página​

Un Blueprint convierte un tipo semántico de página en un destino de WordPress sujeto a reglas. Cree uno distinto para cada forma de contenido materialmente diferente, como página estándar, artículo, solución, documento de arquitectura o página de producto.

Configure deliberadamente estos campos:

  • Page type: identificador de máquina estable utilizado por las operaciones MCP.
  • Target post type: página, entrada o tipo de contenido personalizado aprobado que Composer puede crear.
  • Target template: plantilla registrada por el tema activo. Prefiere una plantilla sin título cuando el patrón aprobado ya contiene el único H1.
  • Allowed patterns: patrones que el agente puede ensamblar para este tipo de página.
  • Required sequence: secuencia mínima ordenada de patrones que debe contener todo borrador válido.
  • Allowed blocks: lista completa de bloques permitidos, incluidos los bloques anidados de cada patrón aprobado.
  • Constraints: reglas de H1, número de palabras, embeds, shortcodes, HTML personalizado y presets del tema.
  • Excerpt policy: required, optional o disabled para este tipo de página.
  • SEO contract: comportamiento requerido para el extracto de WordPress y la metadescripción.
  • Content mode: use document para contenido de bloques Gutenberg y fields para registros estructurados registrados.
  • Approved fields: seleccione únicamente campos visibles por REST registrados para el tipo de destino y declara su política de lectura/escritura.
  • Relation fields: declara cardinalidad, orden, tipos y estados permitidos de los destinos y número máximo de elementos.
  • Taxonomy access: permite búsqueda, asignación o creación confirmada solo para taxonomías descubiertas que estén asociadas al tipo de destino del Blueprint.

Use el selector de bloques registrados en lugar de escribir de memoria sus nombres. Un bloque o patrón proporcionado por otro plugin solo es válido mientras ese proveedor esté instalado, activo y registrado en el sitio.

Para un campo de relación, el sitio o plugin proveedor registra el tipo de entrada, metacampo y contrato de relación subyacentes. Composer gestiona el flujo genérico de ejecución: smartcloud-agent-composer/get-content-field-contract anuncia el flujo, smartcloud-agent-composer/search-relation-targets resuelva títulos o slugs como matches[].id, smartcloud-agent-composer/update-content-fields escriba esos IDs en un borrador asignado propiedad de Composer y smartcloud-agent-composer/inspect-content-fields verifique el valor almacenado. smartcloud-agent-composer/list-content-drafts enumera contenido editable o adoptable y no debe utilizarse para resolver destinos de relaciones.

Gobernar los términos de taxonomía por separado​

El plugin responsable o el núcleo de WordPress sigue registrando cada taxonomía y asociándola al tipo de entrada de destino. En Composer taxonomy access, el Site Contract puede permitir de manera independiente buscar, asignar a borradores y crear términos confirmados para cada taxonomía descubierta. También establece un número máximo de elementos y fija el comportamiento de asignación en append o replace. De forma predeterminada, la creación jerárquica se limita al nivel raíz; una lista opcional de permitidos utiliza slugs duraderos de padres en lugar de IDs locales del sitio.

La secuencia gobernada del agente es get-taxonomy-contract -> search-taxonomy-terms -> reutilizar un matches[].term_id exacto cuando exista -> create-taxonomy-term solo para un término público ausente y justificado, con confirmación explícita -> assign-taxonomy-terms -> inspect-taxonomy-terms. Los términos nuevos requieren un nombre natural, un slug duradero, una descripción independiente para el archivo y el idioma de contenido del Blueprint. Composer no expone edición ni eliminación de términos, y cada asignación permanece limitada a un borrador asignado y propiedad de Composer con tokens de concurrencia actuales.

4. Volver a escanear el sitio activo​

Abra Theme & providers y seleccione Rescan site después de instalar, activar o actualizar un tema o plugin proveedor.

Revise:

  • identidad y versión del tema activo;
  • plantillas y patrones registrados;
  • todos los bloques Gutenberg registrados;
  • patrones a los que hace referencia el Config Set seleccionado;
  • metadatos opcionales y disponibilidad de runtime de los proveedores;
  • cualquier dependencia ausente del contrato.

El descubrimiento informa de capacidades; no reescribe la configuración. Si ha cambiado el tema, clone el conjunto activo y ajuste la copia de trabajo.

5. Preparar y aplicar cambios​

Las ediciones de entidades se preparan en el navegador. Guardar el modal de una entidad no crea inmediatamente otra revisión en la base de datos. La barra de acciones muestra las adiciones, ediciones y eliminaciones confirmadas pendientes para el Config Set seleccionado.

  • Apply modifications escribe el conjunto completo de cambios preparados como una sola transacción protegida por concurrencia optimista.
  • Discard elimina los cambios preparados sin escribir en WordPress.

Al aplicar un conjunto de cambios se recalculan el hash y la fecha de modificación del Config Set. Si otro administrador ha cambiado la misma entidad, Composer devuelve un conflicto en lugar de sobrescribir una de las versiones.

6. Validar y activar​

Seleccione Validate después de cada cambio relevante de contrato, tema, patrón, bloque, plantilla o proveedor. Resuelva los errores antes de activar y revise las advertencias según su contexto.

La activación requiere un recibo de validación reciente vinculado a:

  • el checksum exacto del Config Set;
  • el sitio WordPress actual;
  • el administrador actual;
  • un periodo de validez limitado.

Seleccione Activate solo después de revisar todo el conjunto de trabajo. El conjunto activo anterior queda archivado y siga disponible para compararlo y restaurarlo con confirmación.

Comparar, restaurar, exportar y hacer copias de seguridad​

  • Compare to active muestra las diferencias entre el conjunto seleccionado y la configuración de runtime.
  • Restore archived as active vuelve a validar el conjunto archivado y requiere confirmación explícita; no deshace una edición del navegador que aún no se haya guardado.
  • Export crea un paquete de un Config Set protegido mediante checksum.
  • Audit & portability -> Export all configuration crea una copia completa de todos los Config Sets.

Las exportaciones portátiles excluyen deliberadamente las credenciales y la cadena de auditoría específica del sitio. Los conjuntos restaurados permanecen inactivos hasta que se validan y activan explícitamente.

Ejemplo de entrega de una agencia: un flujo existente de casos prácticos​

Supongamos que una agencia ya ha diseñado un tipo de contenido personalizado case_study, sus plantillas de frontend y el tratamiento visual aprobado. El tema sigue siendo responsable de la presentación; Composer no introduce un diseño universal de casos prácticos de WP Suite.

La agencia puede crear un Config Set que exponga únicamente el flujo pertinente y añadir un Blueprint case_study que exija:

  • título y contexto del cliente;
  • secciones de reto, implementación y resultado;
  • una llamada a la acción aprobada;
  • metadatos de una imagen existente en la biblioteca multimedia;
  • categorías, etiquetas y metadatos SEO permitidos;
  • plantilla, patrones, bloques y secuencia del tema que ya usa el sitio.

Cuando el cliente solicita a su agente compatible un caso práctico nuevo, el agente carga este Blueprint y el contexto de diseño activo, prepara el contenido, valide la estructura completa y cree un borrador. Una persona comprueba los hechos, los medios y la presentación antes de aprobarlo. La publicación mediante WordPress o una versión opcional de Static Publisher sigue siendo una acción independiente.

Esta entrega convierte las decisiones existentes de la agencia en una operación de contenido repetible. No pide a Composer ni al agente del cliente que rediseñen el sitio.

Antes de conectar un agente​

Confirme que:

  1. haya exactamente un Config Set activo;
  2. cada tipo de página solicitado tenga un Blueprint válido;
  3. existan todos los patrones, plantillas y bloques obligatorios;
  4. los proveedores opcionales indiquen que están preparados o no aparezcan en el Blueprint;
  5. el usuario dedicado del agente tenga el rol smartcloud_agent;
  6. el estado MCP de Composer muestre el endpoint previsto.