Preparar y reanudar un plan de sitio web

Un plan de sitio es un documento JSON versionado que contiene operaciones MCP ordenadas. Úsalo cuando crees varias partes dependientes de un sitio web desde un cliente remoto. El diario registra los cambios preparados y los resultados completados para que otra solicitud pueda continuar desde el siguiente paso.

Conéctate a través de POM AI → Settings → MCP. Los planes requieren los ámbitos manage_options y POM Theme para las operaciones del diario y los ámbitos, capacidades y puertas de escritura que exija cada paso. Guardar un plan no concede permisos de los que carezca la conexión actual.

Formato del plan

{
  "version": 1,
  "title": "Site navigation",
  "steps": [
    {"id": "home", "tool": "pom_site_save_content", "arguments": {
      "post_type": "page", "slug": "home", "title": "Home", "status": "publish"
    }},
    {"id": "front", "tool": "wp_set_site_pages", "arguments": {
      "show_on_front": "page", "page_on_front": {"$ref": "home.id"}
    }}
  ]
}

Usa identificadores de paso únicos y referencias solo a resultados de pasos anteriores. Una referencia es un objeto que contiene únicamente $ref; reemplaza el valor completo y conserva su tipo. No se admite la interpolación de cadenas. No incluyas dry_run, expected_revision ni site_id dentro de los argumentos de los pasos: el diario gestiona esos controles. Para plantillas y filas del modelo de contenido, proporciona identificadores estables.

Los planes solo aceptan las herramientas enumeradas en su esquema descubierto: contenido, ajustes, menús, páginas del sitio, formularios, configuración del modelo de contenido, plantillas, CSS global y con nombre, recursos, limpieza de caché del sitio, consultas guardadas, facetas, términos y metadatos. Una operación también debe estar disponible en el sitio conectado. No pueden ejecutar herramientas arbitrarias, PHP, SQL ni solicitudes.

Ejecutar un paso cada vez

1. Envía el documento a pom_site_preview_plan. Esto comprueba su estructura, orden, referencias y las concesiones de operaciones disponibles. Todavía no valida los destinos que dependen de cambios anteriores.
2. Llama a pom_site_create_plan con el mismo documento. Registra el id y el revision devueltos.
3. Llama a pom_site_prepare_plan_step con plan_id y ese expected_revision. Esto resuelve dependencias, ejecuta la vista previa real de la siguiente operación y registra un punto de control. Revisa steps[next_step].preview.
4. Llama a pom_site_apply_plan_step con la revisión más reciente del diario. Vuelve a comprobar el destino y aplica exactamente un paso. Inspecciona el status devuelto por ese paso; una solicitud correcta por sí sola no significa que la operación se haya completado.
5. Repite la preparación y la aplicación hasta que complete sea verdadero. Cada solicitud carga de nuevo los tipos de contenido registrados y las opciones de funciones del sitio.
6. Lee pom_site_get_plan después de cualquier respuesta perdida o desconexión. Los pasos completados se conservan y no se ejecutan de nuevo. Vuelve a conectarte después de un cambio de modo de transporte.

La preparación, la aplicación y la recuperación también aceptan dry_run: true. Una ejecución de prueba no actualiza el diario ni aplica cambios en el sitio web. Las vistas previas de escritura siguen exigiendo los mismos permisos y consumen una ranura de escritura. Respeta el límite de escritura de MCP y continúa después de su restablecimiento.

Conflictos y resultados inciertos

Un diario o destino modificado exige una nueva preparación y revisión. Las escrituras MCP se serializan por sitio; un destino ocupado pide al cliente que lo intente más tarde. Las ediciones a través de otras interfaces de WordPress se comprueban mediante revisiones de destino y huellas preparadas, sin bloquear esas interfaces. Una solicitud interrumpida durante la ejecución deja running o uncertain; estos estados nunca se reproducen automáticamente.

Para guardados de contenido interrumpidos, inspecciona el elemento y usa pom_site_adopt_plan_content con su content_id y la revisión actual del diario. Todos los campos de contenido editables deben coincidir con el resultado preparado. Para una creación de formulario interrumpida, pom_site_find_forms ayuda a localizar el borrador; pom_site_adopt_plan_form acepta solo el borrador intacto coincidente creado por el mismo usuario. Ambas operaciones de recuperación admiten vista previa.

Otras operaciones inciertas requieren inspeccionar y reparar los objetos afectados y, a continuación, crear un plan revisado que omita los cambios ya aplicados. Los puntos de control y los valores originales respaldan la revisión y la restauración manual; no proporcionan reversión automática ni una transacción a nivel de todo el sitio. Los ganchos de tema o las operaciones de varios archivos pueden completarse parcialmente antes de un error.

Un diario pertenece a su usuario de WordPress, cliente y sitio. Otra conexión no puede reclamarlo solo con conocer su identificador. Los permisos actuales se vuelven a comprobar cuando se usa. Mantén la misma identidad de cliente al reconectarte.

Retención y verificación

Un sitio puede conservar 20 diarios. Cada documento admite hasta 100 pasos y 512 KiB de entrada; un diario que incluye vistas previas y resultados está limitado a 4 MiB. Prefiere planes pequeños para contenido extenso. Usa pom_site_discard_plan en la revisión actual para eliminar un diario cuando ya no se necesite su registro. Descartarlo conserva los cambios del sitio web.

Tras la finalización, inspecciona el frontend: navegación, asignaciones de páginas, plantillas, validación de formularios, cookies, barra de contacto, controles de listado y diseño adaptable. Un diario completado registra operaciones correctas; no sustituye esta revisión en el navegador.

Relacionado: Ajustes con tipo, listados filtrables, formularios y navegación.