Kodavio

Primeros pasos

Guía práctica operativa

Guía práctica operativa

Esta guía está pensada para ejecutar trabajo real sin improvisar: diagnosticar, planificar, probar en dry_run, confirmar y aplicar.

1) Diagnóstico inicial (siempre primero)

Texto recomendado:

Quiero un diagnóstico inicial del sitio con Kodavio.

Solo lectura:
- conexión MCP y capacidades disponibles;
- constructores detectados;
- plugins clave;
- estado de design.md y scope.md;
- riesgos antes de escribir.

No hagas cambios.

Salida esperada:

  • mapa de capacidades real para ese sitio;
  • riesgos y límites;
  • siguiente paso recomendado.

2) Crear una página nueva en borrador

Texto recomendado:

Quiero crear una página nueva en borrador.

Primero:
- lee design.md y scope.md si existen;
- lee `kodavio/design-get-system` y `kodavio/builder-get-config`;
- propón texto, jerarquía y secciones;
- prepara `content_model.sections` (o `blocks` si es Gutenberg);
- ejecuta dry_run.

No escribas nada hasta mi confirmación.

Confirmación de escritura:

Aprobado. Ejecuta la creación real con confirm_write=true.
Devuélveme ID, enlace de edición y avisos.

3) Editar una página existente sin romper producción

Texto recomendado:

Quiero ajustar la página [ID].

Primero solo lectura:
- identifica el constructor;
- resume estructura actual;
- plan de cambios por secciones;
- dry_run de la operación.

No publiques ni borres nada.

Buena práctica:

  • si el cambio es grande, crea borrador nuevo;
  • no reescribas toda la página si solo cambian bloques concretos.

4) Importar sistema de diseño desde el sitio

Texto recomendado:

Ejecuta importación de diseño en dry_run.

Necesito:
- tokens detectados;
- limpieza de ruido;
- qué quedaría en design.md;
- avisos y supuestos.

No escribas todavía.

Después:

Aprobado. Escribe design.md con confirmación explícita y devuelve resumen de cambios.

5) Transpilar tokens al constructor activo

Texto recomendado:

Quiero transpilar design.md al constructor activo.

Paso 1: dry_run con `capability_matrix` y `mapping_report`.
Paso 2: no escribas hasta confirmar.
Si falta soporte nativo, usa alternativa de clases y variables.

Lista mínima de verificación:

  • qué fue compatible, aplicado, omitido o resuelto con alternativa por grupo;
  • artefactos creados;
  • pasos manuales pendientes.

Bricks y Elementor (regla de estilo)

Prioriza siempre clases globales y tokens del sistema. Evita CSS personalizado en widgets salvo excepción explícita y justificada.

6) Convertir una página entre constructores

Texto recomendado:

Convierte la página [ID origen] a [constructor destino] como borrador nuevo.

Condiciones:
- no tocar la original;
- usar design.md;
- marcar widgets/partes no soportadas;
- dry_run primero;
- tras confirmar, crear borrador y pasar comprobación de salud.

Entrega esperada:

  • ID del borrador destino;
  • diferencias clave origen/destino;
  • lista de ajustes manuales.

7) Operaciones sensibles (plugins/PHP/destructivo)

Texto recomendado:

Antes de cualquier operación sensible:
- ejecuta dry_run;
- muestra impacto;
- pide confirmación destructiva.

No ejecutes borrados ni cambios de PHP sin confirmación explícita.

Patrón recomendado

Si una tarea tiene riesgo: lectura -> plan -> dry_run -> confirmación -> escritura -> verificación final.

Previous
Primera prueba