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.