Administracion segura

Kodavio incluye herramientas de administracion WordPress, pero estan agrupadas y protegidas para evitar cambios accidentales.

La administracion se divide en lectura, escritura gestionada y escritura elevada. En la practica significa que Codex puede ayudarte a operar el sitio, pero las acciones peligrosas quedan separadas, visibles y protegidas.

Acciones de bajo riesgo

Normalmente puedes pedir sin riesgo alto:

• Listar plugins instalados.
• Ver el tema activo.
• Leer diagnosticos del sitio.
• Leer memoria de diseno.
• Listar patrones o paginas sin modificarlas.
• Leer settings soportados mediante adapters explicitos.
• Listar mu-plugins y validar sintaxis PHP.
• Leer resumen de WooCommerce sin datos personales.

Acciones delicadas

Requieren mas cuidado:

• Instalar, borrar o actualizar plugins.
• Escribir o borrar mu-plugins.
• Actualizar paginas existentes.
• Migrar contenido entre builders.
• Limpiar datos antiguos de un builder.

Gestion de plugins

Codex puede trabajar con el ciclo de vida de plugins mediante habilidades dedicadas:

Cuando instales desde ZIP local, el plugin solo debe aceptar paquetes dentro de la carpeta permitida en uploads. Esto evita que Codex use rutas arbitrarias del servidor.

Prompt recomendado:

Revisa si el plugin [slug] esta instalado y si hay actualizacion disponible.

Primero solo dry_run:
- dime version actual y version objetivo;
- indica si requiere licencia o dependencias;
- explica el riesgo;
- no actualices nada hasta que confirme.

Settings de plugins

No hay una lectura generica de wp_options. Esto es deliberado. Cada plugin soportado necesita un adapter con schema propio.

El flujo correcto es:

1. Pedir el schema de settings soportados.
2. Leer solo los campos permitidos.
3. Redactar secretos, licencias, passwords, tokens y claves privadas.
4. Escribir solo valores validados por el adapter.
5. Devolver resumen y auditoria.

Si un plugin no esta soportado, Codex debe devolver un resultado unsupported y proponer crear un adapter, no inventarse escrituras.

Configurar WordPress

Tu agente puede cambiar la configuración del sitio sin que entres en el panel. Lo hace por las rutas oficiales de WordPress, así que las reglas y los permisos son los de WordPress.

Cada cambio sigue el mismo orden:

1. El agente lee el valor actual.
2. Te enseña el antes y el después en un ensayo. No se escribe nada.
3. Tú confirmas. En los cambios de confirmación doble, el agente necesita además tu visto bueno expreso a ese cambio concreto.
4. Kodavio guarda una copia del valor anterior, escribe y devuelve una referencia (op_id) para deshacerlo. Ver Deshacer un cambio.

Barandillas que no se saltan:

• Nunca se degrada ni se desactiva al último administrador.
• Los roles de WordPress (administrador, editor, autor, colaborador, suscriptor) no cambian sus permisos. Si necesitas otros permisos, se crea un rol aparte.
• Nadie puede dar un permiso que no tiene.
• Un usuario nuevo se crea sin contraseña: WordPress genera una y la persona la cambia. El correo de bienvenida solo se envía si lo pides.
• Las contraseñas y claves no se leen ni se escriben.
• Lo que no está en la lista de arriba se rechaza con el motivo.

Prompt recomendado:

Cambia la portada del sitio a la página «Inicio» y la página de entradas a «Blog».

Primero enséñame el antes y el después, sin escribir.
Cuando confirme, haz el cambio, comprueba la portada en el sitio
y dame la referencia para deshacerlo.

El agente tiene una guía propia para esto, configurar-sitio. Si no la usa, pídele que la cargue con kodavio/skill-get.

Configurar la tienda (WooCommerce)

Con WooCommerce activo, tu agente también configura la tienda, con el mismo orden: ensayo, confirmación, copia y marcha atrás. Va por las rutas oficiales de WooCommerce, así que valida lo mismo que el admin de WooCommerce.

Barandillas de la tienda:

• Las claves de las pasarelas no viajan. El agente las ve como [redacted] y no puede escribirlas: las pone una persona en el admin de WooCommerce.
• Salir del modo pruebas de una pasarela avisa de que a partir de ahí los cobros son de verdad.
• Un webhook envía datos de la tienda a una dirección de fuera. Antes de confirmar, el ensayo te dice qué datos (por ejemplo, el pedido completo con los datos del cliente) y a qué dirección. Su clave de firma tampoco se enseña.
• Un cliente nuevo no recibe el correo de cuenta nueva salvo que lo pidas.
• Lo que WooCommerce ya hace con sus propias capacidades, si tu sitio las tiene, se queda en WooCommerce.

Prompt recomendado:

Pon la pasarela Redsys en modo pruebas.

Primero enséñame el antes y el después, sin escribir.
Cuando confirme, haz el cambio, comprueba el ajuste
y dame la referencia para deshacerlo.

Comprobado en una tienda de pruebas con WooCommerce 10.6: dirección de la tienda, zona de envío con tarifa plana, transferencia bancaria desactivada y con otro título (el checkout la deja de ofrecer), Redsys en modo pruebas y de vuelta, claves tapadas, webhook de pedidos, teléfono de un cliente, imágenes de un producto y precio de una variación, con su marcha atrás.

mu-plugins

Los mu-plugins son potentes porque cargan siempre. Por eso el plugin los trata como administracion elevada.

Pide siempre que el cambio sea minimo y que Codex explique que hook, filtro o funcion va a introducir.

Archivos PHP de plugins y themes

Kodavio tambien puede operar sobre archivos .php dentro de wp-content/plugins, wp-content/themes y wp-content/mu-plugins cuando el propietario activa esas abilities elevadas.

Si el codigo incluye eval, exec, shell_exec, system, proc_open, popen, pcntl_exec o similares, Kodavio lo bloquea salvo que se pase allow_dangerous_code=true despues de aceptar explicitamente el riesgo.

Los backups de PHP quedan en wp-content/kodavio-code-backups, con metadatos de origen. Una restauracion real tambien crea backup del archivo actual antes de sustituirlo.

Fragmentos de código

Si el sitio tiene un gestor de fragmentos (Fluent Snippets, Code Snippets o WPCode), tu agente escribe ahí el código en vez de tocar ficheros. A partir de la 0.3.2, con Fluent Snippets:

• Escribe fragmentos JS, además de PHP y CSS.
• Los fragmentos JS y CSS pueden cargarse solo en las páginas que digas, en vez de en todo el sitio.
• Al crear un fragmento, la respuesta dice si quedó publicado o en borrador, y por qué.
• Si Fluent Snippets deja fuera de su índice un fragmento publicado (por ejemplo, porque su cabecera está mal formada), ese fragmento deja de ejecutarse. Kodavio avisa al escribir el siguiente y dice cómo arreglarlo.

Formularios

A partir de la 0.3.2, tu agente puede editar un formulario de Fluent Forms sin cambiarle el id, así que su shortcode sigue funcionando en todas las páginas donde está. Guarda copia del formulario y se puede deshacer.

Si en cambio le pides importar un formulario, crea uno nuevo, con id y shortcode nuevos. Por ahora la edición solo funciona con Fluent Forms.

Contenido, media y usuarios

Tambien hay habilidades para listar y leer posts, paginas, media y usuarios de forma segura. Para crear o actualizar contenido, pide:

• dry_run=true;
• estado draft salvo que tengas claro que debe publicarse;
• resumen de campos modificados;
• ID y enlace del objeto afectado;
• avisos sobre builder markers o contenido no compatible.

Slug, orden y papelera

A partir de la 0.3.2, tu agente puede:

• Dar o cambiar el slug de una página o entrada, y su orden en el menú. Si cambias el slug de algo publicado, la URL antigua redirige a la nueva.
• Mandar a la papelera y restaurar. Al restaurar, la página vuelve con el estado que tenía. Kodavio nunca borra del todo: si el sitio no tiene papelera, se niega.

Subir medios y fuentes

Tu agente puede subir ficheros a la mediateca sin que tú los subas a mano:

Deshacer una subida borra el fichero subido. No pasa por la papelera.

Ver un cambio antes de publicarlo

Tu agente puede ver una página como la vería un visitante, borradores incluidos. Recibe el código de respuesta, el título, el HTML y las hojas de estilo y scripts que se cargan.

También puede ver un cambio antes de escribirlo: lo aplica solo en esa vista previa y la página publicada no se toca. Sirve para el contenido de páginas y entradas del editor de WordPress, y para páginas y plantillas de CrocoBuilder.

Prompt recomendado:

Quiero cambiar el texto de la página «Servicios».
Antes de escribir nada, enséñame una vista previa con el cambio
y confírmame que la página publicada sigue igual.

La comprobación de salud de una página también lee la página servida: detecta la pantalla de error de WordPress aunque llegue con código 200 y, en Bricks, que la página y su CSS se han cargado. Funciona igual con cabeceras, pies y plantillas de archivo.

WooCommerce y analitica

Las habilidades de WooCommerce estan pensadas para lectura segura y cambios muy acotados, como actualizar precio regular o precio rebajado de un producto concreto.

No deberian exponer datos personales de clientes. Para tareas comerciales importantes, pide siempre resumen, filtros usados, rango temporal y confirmacion antes de cambios de precio.

Si tu sitio tiene las capacidades propias de WooCommerce para productos y pedidos, Kodavio oculta las suyas que hacen lo mismo y remite a las de WooCommerce. Se quedan las que aportan algo más: precio y stock con ensayo y copia, informe de ventas y resumen de pedidos sin datos personales. La configuración de la tienda la hace Kodavio (ver Configurar la tienda).

Tools

En Kodavio > Tools se activan grupos de herramientas. Para uso normal, activa solo los grupos que necesitas. Los detalles avanzados sirven para afinar una ability concreta cuando ya sabes que quieres hacer.

La interfaz esta pensada para trabajar por grupos:

• Activa primero la familia general.
• Despliega detalles solo si necesitas una ability concreta.
• Mantiene desactivadas las acciones elevadas hasta que haya una razon real.
• Vuelve a cerrar o desactivar el grupo cuando termines una operacion puntual.

Si una capacidad está apagada

A partir de la 0.3.2, una capacidad apagada ya no parece inexistente. En el mapa de capacidades sale como apagada, con el grupo de Kodavio › Herramientas › Permisos donde se enciende. Si el agente la llama igualmente, recibe ese mismo mensaje.

Solo un administrador puede encenderla. El agente no puede hacerlo por ti.

Corregido en la 0.3.2: las capacidades de formularios y SEO desaparecían al guardar la pestaña Permisos. Ahora tienen sus tarjetas, Formularios y SEO, y los sitios donde se apagaron así las recuperan solas una vez.

Ajustes operativos del agente

El bloque Comportamiento del agente no concede permisos nuevos. Envia preferencias al agente para decidir cuanta supervision aplicar antes de leer, planificar, simular o escribir.

El modo tester para builders refuerza tres habitos:

• preflight antes de tocar builders o tokens;
• lectura del arbol antes de editar paginas existentes;
• verificacion posterior con warnings visibles.

Este modo ayuda a detectar errores de metodologia, pero no debe convertir cada tarea simple en una auditoria lenta. Para una tarea pequena y bien acotada, como anadir dos colores semanticos al tema, el agente debe tocar solo ese grupo de tokens y no reconstruir el sistema entero.

Privacidad, diagnostico y limpieza

El segundo bloque de ajustes controla que datos tecnicos conserva Kodavio y que ocurre al desinstalar.

Modo fantasma

El modo fantasma oculta Kodavio a los administradores del sitio que tú elijas. Sirve, por ejemplo, para trabajar en la web de un cliente sin que el plugin aparezca en su panel.

Se activa en Kodavio › Herramientas › Mantenimiento, en el bloque Modo fantasma: enciende el interruptor, marca los administradores que sí deben verlo y guarda. Tú quedas siempre en la lista al guardar, así que no puedes ocultártelo a ti mismo por error.

Para los administradores que no están en la lista:

• desaparece el menú Kodavio;
• Kodavio no sale en la lista de Plugins ni en Actualizaciones;
• no ven los avisos de Kodavio;
• si abren una página de Kodavio por su dirección, WordPress les responde que no tienen permiso.

Tu agente sigue trabajando igual: la conexión MCP, las habilidades y las tareas programadas no cambian. El modo fantasma solo cambia lo que se ve en el panel de WordPress.

Deshacer un cambio

Las escrituras que guardan copia (configuración, contenido, medios, formularios, plantillas de CrocoBuilder, caché de WindPress, ajustes de Bricks…) devuelven una referencia, op_id. Con ella, tu agente puede deshacer ese cambio concreto:

Deshaz el cambio con op_id [referencia].
Primero en ensayo: dime qué se va a restaurar. No lo hagas hasta que confirme.

A partir de la 0.3.2, deshacer viene encendido de serie y no necesita licencia: basta con ser administrador, lo mismo que para la escritura que se deshace.

La excepción es el código. Deshacer una escritura en ficheros de código, mu-plugins o fragmentos PHP y JS vuelve a escribir código, así que necesita encendido el permiso que escribe ese código. Si está apagado, Kodavio dice cuál es y dónde se enciende.

Si lo tenías apagado en una versión anterior, se enciende una sola vez al actualizar. Si después lo vuelves a apagar, Kodavio lo respeta.

Auditoria

Las acciones administrativas devuelven resumen, avisos y datos de auditoria siempre que es posible. Si Codex no puede verificar el resultado final, pide que deje la tarea en revision en vez de asumir que esta terminada.

Para tareas delicadas, una buena respuesta debe incluir:

• ability ejecutada;
• objeto afectado;
• dry_run o cambio real;
• si hubo backup;
• warnings;
• proximos pasos manuales;
• entrada de audit log o referencia equivalente.