Beta publica

Kodavio ya puede probarse en sitios reales, pero la beta publica debe abrirse con alcance controlado. El objetivo de esta fase no es prometer automatizacion total: es validar conexion MCP, comprension de builders, memoria del proyecto, administracion segura y trazabilidad.

La version de referencia para esta guia es 0.1.2, preparada para pruebas internas. No debe servirse todavia como actualizacion automatica hasta completar verificacion final.

Durante la beta publica, las actualizaciones se sirven desde el proxy de Flowtitude y la numeracion avanzara sobre la rama 0.1.x. Los sitios que vengan de betas internas con numeracion superior pueden requerir reinstalacion manual del ZIP inicial 0.1.0.

Estado actual de apertura

El circuito automatizado de pruebas esta en verde y la validacion read-only autenticada contra kodavio.es ya pasa en dos paginas reales. Abre testers solo en alcance controlado y staging, no como beta publica amplia.

La beta publica amplia debe esperar a que:

se pruebe la instalacion del ZIP 0.1.2 desde el panel de WordPress;
se ejecute una prueba real pequena y reversible de escritura/conversion en kodavio.es;
se verifique rollback o limpieza de la prueba;
se publique el paquete en el canal de actualizaciones solo despues de aprobar estas comprobaciones.

Alcance recomendado

Bricks como builder prioritario de la beta.
Elementor y Gutenberg disponibles como soporte foundation: utiles para lectura, pruebas controladas y flujos seleccionados, sin prometer paridad completa con Bricks.
Sitios de staging, demos o proyectos donde puedas revisar antes de publicar.
Demo beta local de 30 dias, iniciada automaticamente al activar el plugin, mientras se termina el checkout/licenciamiento comercial.
Acciones elevadas desactivadas por defecto.
Documentacion publica disponible en https://guias.flowtitude.com/kodavio/.

Checklist antes de invitar testers

Instalar el ZIP en staging.
Confirmar en Kodavio > License que la demo local empezo al activar el plugin, o pegar licencia si ya existe.
Crear la Application Password en Kodavio > Connect.
Conectar Codex o el cliente MCP elegido.
Ejecutar kodavio/capability-map.
Ejecutar kodavio/agent-handbook.
Ejecutar kodavio/wp-get-config-summary y revisar beta_readiness.
Leer design.md y scope.md si existen.
Cargar el playbook adecuado con kodavio/skill-list y kodavio/skill-get si vas a tocar builders, frameworks o integraciones.
Crear una pagina de prueba en dry_run.
Crear un borrador real solo despues de revisar el dry-run.
Abrir el borrador en el builder y comprobar que sigue siendo editable.
Revisar Kodavio > Tools > Audit log antes de cerrar la prueba.

Builders y almacenamiento

Las paginas, templates, componentes y patrones generados por Kodavio deben guardarse como entidades de WordPress o del builder: posts, post meta, Bricks templates, Elementor library o wp_block.

No escribas plantillas generadas dentro del tema hijo por defecto. Los archivos fisicos del tema hijo pertenecen al ciclo de release de FlowKit y pueden ser sustituidos en una actualizacion.

Si una pieza generada debe pasar al tema, exportala como artefacto revisado y deja que FlowKit la incorpore en una version del tema.

Cierre de sesion beta

Antes de dar una prueba por buena, conserva estas evidencias:

herramientas MCP detectadas;
resumen de builders/plugins;
pagina o componente creado en borrador;
warnings devueltos por Kodavio;
entrada de audit log;
notas sobre lo que el agente entendio mal;
pasos manuales pendientes.

Bloqueos fuera del plugin

La landing publica, el checkout, FluentCart, webhooks post-compra, video demo y secuencia comercial viven fuera de este plugin. El plugin puede soportar la beta, pero la apertura publica depende tambien de esa fachada comercial.

Senales para no abrir mas testers todavia

Frena la apertura si aparece cualquiera de estas senales:

beta_readiness.status devuelve blocked;
el servidor no puede validar PHP y quieres probar edicion de archivos;
el MCP no lista capacidades o las lista en el workspace equivocado;
el builder de destino no abre el borrador generado;
el agente escribe sin haber mostrado dry_run;
no queda rastro en el audit log de una operacion relevante.
el runtime de staging no responde por URL o WP-CLI no conecta a base de datos.