Producción no es un laboratorio
Un agente puede instalar dependencias, editar archivos y navegar una interfaz con una velocidad que resulta tentadora. Esa velocidad no vuelve aceptable probar un plugin en el sitio que vende, publica o captura datos de clientes. Un error de activación, una migración incompatible o una limpieza incompleta puede dejar un efecto real antes de que alguien alcance a revisar la conversación.
WordPress Playground permite ejecutar WordPress en un entorno desechable. La instalación se crea para la prueba, recibe sólo los archivos necesarios y puede descartarse al terminar. El objetivo no es simular cada detalle de producción. Es comprobar comportamiento funcional en una frontera donde un fallo no toca el sitio público.
La regla operativa es simple: el agente trabaja dentro del laboratorio; una persona decide si la evidencia justifica avanzar a un entorno de staging. Producción queda fuera del alcance.
Qué aporta Playground al ciclo de un agente
La habilidad oficial de WordPress para agentes puede iniciar Playground mediante su CLI y montar plugins o temas a partir de las rutas del proyecto. El agente obtiene un sitio real para activar el código, abrir páginas y comprobar resultados con solicitudes HTTP o automatización de navegador.
El paquete oficial de MCP para Playground añade herramientas para administrar el sitio de prueba, ejecutar PHP, navegar y trabajar con el sistema de archivos. Eso reduce pegamento artesanal, pero no elimina la necesidad de limitar herramientas. Una prueba de plugin no necesita credenciales de producción, administración de dominios ni acceso a copias con datos personales.
Playground es una pieza del arnés de prueba. El contrato, los casos y la evidencia siguen siendo responsabilidad del equipo.
Prepara un laboratorio local y repetible
Parte desde una copia limpia del plugin y una versión de WordPress y PHP declaradas. No uses secretos reales en archivos de configuración. Si necesitas datos, crea fixtures pequeños y sintéticos: entradas falsas, usuarios de prueba y opciones conocidas.
Define un comando único que levante el entorno. La habilidad oficial puede instalarse con la herramienta indicada por WordPress y sincronizarse para el cliente agéntico compatible. Si prefieres MCP, instala el paquete oficial en el proyecto de laboratorio y expón sólo las operaciones requeridas. En ambos casos, conserva las versiones en el repositorio para que otra persona pueda repetir la misma ejecución.
Antes de invocar al agente, verifica manualmente que el sitio desechable inicia, que el plugin se monta y que no existe una ruta de red hacia producción. Un sandbox mal conectado sólo da una falsa sensación de seguridad.

Escribe el contrato de prueba antes del prompt
El contrato debe nombrar el artefacto, la versión, la entrada y la salida esperada. Por ejemplo: activar el plugin, crear una entrada sintética, invocar una función concreta, comprobar el resultado, capturar errores y dejar el sitio limpio. Indica qué no puede hacer: instalar paquetes no declarados, acceder a internet, usar credenciales, modificar el repositorio o salir del directorio montado.
Añade criterio de término. La tarea no termina cuando el agente dice que todo funciona, sino cuando entrega un conjunto definido: versión del entorno, comandos ejecutados, resultados de los casos, capturas o respuestas, errores y estado de limpieza.
Si el plugin modifica datos al activarse, incluye una comprobación de desactivación y borrado. El camino feliz demuestra poco si el reverso deja tablas, capacidades o tareas programadas sin documentar.
Seis casos mínimos de aceptación
1. Activación limpia: no aparecen errores fatales ni avisos inesperados.
2. Función principal: la entrada sintética produce la salida definida.
3. Permisos: un usuario sin capacidad suficiente recibe rechazo.
4. Entrada inválida: el plugin falla de forma controlada y no persiste basura.
5. Desactivación y limpieza: el estado final coincide con el contrato.
6. Repetición: una segunda ejecución no duplica efectos.
Para cada caso registra precondición, pasos, observación y veredicto. Un test bloqueado por una dependencia ausente se informa como BLOCKED, no como PASS. Un comportamiento distinto al esperado es FAIL aunque la pantalla parezca estable.
El agente puede ejecutar los pasos; el arnés debe decidir los estados con reglas estructuradas siempre que sea posible.

Reduce la superficie de herramientas
Entrega lectura del código, ejecución dentro de Playground, navegador del sandbox y acceso al directorio temporal. Mantén fuera SSH, panel de hosting, credenciales de WordPress, correo y gestores de dominios. Si una prueba exige una llamada externa, usa un servidor simulado o una cuenta de prueba explícita.
Valida los argumentos antes de cada herramienta. Una ruta debe resolverse dentro del workspace permitido; una orden PHP debe tener tiempo máximo; una navegación debe restringirse al origen local. Registra nombre de herramienta, parámetros no sensibles, resultado y duración.
La autorización de la conversación no reemplaza estos límites. El sistema debe impedir el salto aunque el modelo interprete mal una instrucción incrustada en una página o archivo.
Conserva evidencia que otra persona pueda repetir
Guarda un reporte con identificador de ejecución, commit del plugin, versiones, casos y resultados. Adjunta sólo capturas útiles; una imagen sin paso ni expectativa es decoración. Para respuestas HTTP, conserva estado y campos pertinentes sin tokens ni cookies. Para cambios de datos, compara el estado previo y posterior.
Descarta el Playground al terminar y vuelve a ejecutar desde cero. Si el segundo recorrido depende de residuos del primero, encontraste un defecto en la prueba o en el plugin. La repetición limpia es la prueba de que el laboratorio realmente es desechable.
Una ejecución verde habilita revisión de staging, no despliegue automático. Producción requiere su propia aprobación, respaldo, ventana y plan de reversa.
Receta local para empezar
1. Fija versiones de WordPress, PHP y plugin.
2. Crea datos sintéticos y elimina secretos del entorno.
3. Levanta Playground con un comando reproducible.
4. Expón al agente sólo archivos y herramientas del sandbox.
5. Define seis casos con resultado esperado.
6. Ejecuta, captura evidencia y clasifica PASS, FAIL o BLOCKED.
7. Verifica permisos, entradas inválidas y repetición.
8. Desactiva, limpia y destruye el entorno.
9. Repite desde cero.
10. Envía el reporte a revisión humana antes de staging.
El beneficio no es que el agente tenga más libertad. Es que puede trabajar rápido dentro de una frontera cuyo estado inicial y final se conocen.






