Crear Paginas Como Borrador En Un Sitio Conectado

Estado: guia propuesta para fase 2

Fecha: 2026-05-09

Esta guia describe el flujo esperado para crear paginas como borrador en un sitio web conectado por MCP. El primer conector previsto es Flowtitude Builder Bridge para WordPress, Bricks y Elementor.

Para Que Sirve

Sirve para pedir desde OPS una pagina nueva sin tener que entrar primero al builder. OPS orquesta la tarea, el agente prepara la propuesta y el sitio conectado crea el borrador mediante MCP.

El objetivo no es publicar automaticamente. El objetivo inicial es acelerar la creacion de borradores revisables.

Antes De Empezar

Necesitas:

un workspace activo;
un proyecto asociado al sitio;
una credencial del sitio guardada en OPS;
un conector MCP del sitio validado;
abilities de lectura disponibles;
ability de creacion de pagina disponible para el builder correspondiente;
politica de seguridad que fuerce salida como borrador.

Si falta alguna de estas piezas, la tarea debe quedar bloqueada con una explicacion concreta.

Paso 1: Crear O Seleccionar El Sitio

En el proyecto, selecciona el sitio destino. El sitio debe mostrar:

nombre legible;
entorno: staging o production;
endpoint MCP;
estado de conexion;
builder detectado;
ultima sincronizacion de abilities.

Para la fase inicial, staging debe ser preferente. Produccion puede permitirse solo si la accion genera borradores y no modifica contenido publicado.

Paso 2: Verificar Capacidades

Antes de crear una pagina, OPS debe comprobar que el sitio responde y que las abilities necesarias existen.

Comprobaciones minimas:

conexion MCP activa;
tools/list responde;
ability de lectura del sitio disponible;
ability de lectura de diseno o memoria disponible si el sitio la ofrece;
ability de creacion de pagina en borrador disponible;
abilities destructivas desactivadas o fuera del flujo.

Esta verificacion reduce errores raros: builder no disponible, credencial caducada, endpoint incorrecto o plugin incompleto.

Paso 3: Crear La Tarea De Diseno

La tarea debe decir con claridad que se quiere crear un borrador.

Ejemplo:


Crear una landing como borrador para el servicio de auditoria de automatizaciones.

Sitio: solucionesabiertas.es staging.

Builder: Bricks si esta disponible.

Idioma: espanol.

Objetivo: explicar el servicio y conseguir solicitudes de diagnostico.

No publicar. Dejar en review con URL del borrador y resumen.

La tarea debe incluir:

objetivo de la pagina;
publico;
idioma;
sitio destino;
builder preferido;
restricciones visuales;
referencias opcionales;
confirmacion de que la salida es borrador.

Paso 4: Propuesta Antes De Ejecutar

Cuando la tarea sea compleja o afecte a un sitio real, el agente debe proponer antes de ejecutar.

La propuesta debe incluir:

estructura de la pagina;
secciones principales;
enfoque visual;
copy resumido;
componentes previstos;
riesgos o dudas;
abilities que va a usar.

Si necesita decision humana, la tarea pasa a waiting con una pregunta concreta. No basta con dejar un comentario escondido.

Paso 5: Dry-Run Cuando Exista

Si Flowtitude o el conector ofrecen dry-run, OPS debe usarlo antes de crear el borrador real.

El dry-run debe devolver:

que se habria creado;
en que sitio;
con que builder;
que titulo o slug tendria;
si hay warnings;
si falta alguna capacidad.

OPS guarda este resultado como evidencia en la tarea.

Paso 6: Crear El Borrador

Tras aprobacion o politica permitida, el agente crea la pagina.

Reglas:

estado WordPress: draft;
no publicar;
no sobrescribir una pagina existente sin confirmacion;
no modificar paginas publicadas;
guardar URL del borrador;
guardar identificador interno de pagina si el conector lo devuelve.

Paso 7: Verificar

Despues de crear el borrador, el agente debe verificar.

Comprobaciones recomendadas:

la pagina existe;
se puede recuperar por API/MCP;
el arbol del builder es valido si hay ability disponible;
el editor abre si existe check disponible;
no hay errores de health check si procede;
la tarea contiene evidencia suficiente.

Si alguna verificacion falla, la tarea no debe cerrarse. Debe pasar a review con advertencias o a waiting si requiere decision.

Paso 8: Revisar En OPS

La tarea queda en review con:

URL del borrador;
resumen de lo creado;
estructura generada;
warnings;
checks ejecutados;
proximo paso recomendado.

Desde ahi el usuario decide si acepta, pide cambios o descarta.

Estados Que Debe Usar El Flujo

next: idea lista para priorizar.
doing: agente trabajando.
waiting: falta decision humana.
review: borrador/propuesta listo para revisar.
done: aceptado por el usuario.

La regla practica es simple: si el sistema espera algo del usuario, debe estar en waiting; si el usuario debe revisar un resultado, debe estar en review.

Problemas Frecuentes

El sitio no aparece

Revisar que el conector esta creado en el workspace correcto y que el proyecto lo tiene asociado.

El agente no puede crear pagina

Revisar abilities sincronizadas. Puede existir MCP, pero no la ability concreta de creacion para Bricks o Elementor.

La credencial falla

Renovar la credencial del sitio y repetir smoke test. No copiar credenciales en comentarios de tareas.

El resultado no se puede verificar

No cerrar la tarea. Dejarla en review con advertencia o en waiting si hace falta decidir si se reintenta.

El sitio esta en produccion

Mantener la salida como borrador. No publicar ni editar paginas publicadas sin confirmacion explicita.

Resumen

El flujo correcto no es "agente hace magia y publica". El flujo correcto es:

conectar sitio;
comprobar capacidades;
crear tarea clara;
proponer;
crear borrador;
verificar;
revisar.

Esto mantiene OPS simple para el usuario y seguro para el sitio.