Uso diario
Scope y exportacion
Scope y exportacion
Kodavio separa dos memorias complementarias:
| Memoria | Responde a | Uso principal |
|---|---|---|
design.md | Como debe verse el sitio. | Tokens, componentes, tipografia, spacing, estilos y sistema visual. |
scope.md | Que sitio hay que construir. | Brief, sitemap, plugins, integraciones, backlog y plan de trabajo. |
Esta separacion permite que Codex pueda trabajar tanto en sitios existentes como en proyectos desde cero.
Project Scope
El scope guarda informacion estrategica y operativa:
- nombre, URL, estado y brief;
- publico objetivo y objetivos;
- sitemap previsto;
- templates y patrones necesarios;
- plugins instalados y recomendados;
- integraciones;
- formularios;
- backlog;
- fase actual y proximas acciones.
Abilities principales:
| Ability | Para que sirve |
|---|---|
kodavio/scope-read | Leer scope.md estructurado. |
kodavio/scope-write | Guardar o fusionar cambios en scope.md. |
kodavio/scope-import-from-site | Crear scope desde el sitio actual. |
kodavio/scope-plan-new-site | Planificar un sitio desde un brief. |
kodavio/scope-gap-analysis | Comparar scope con el sitio real. |
kodavio/site-build-plan | Obtener plan por fases. |
kodavio/site-build-next-step | Saber que conviene hacer ahora. |
Campos semanticos por item
scope-write conserva contexto item a item en sitemap.pages, sitemap.templates, sitemap.patterns e integrations. Puedes seguir usando listas simples de texto, pero cuando el agente necesite mas precision conviene usar objetos.
Campos recomendados:
role: funcion del item dentro del proyecto.owner: responsable operativo o area propietaria.notes: contexto que no debe perderse al normalizar.status: por ejemploplanned,draft,liveoarchived.builder_preference: builder recomendado para ese item concreto.meta: datos adicionales estructurados.
Los campos seguros que no formen parte del esquema principal se conservan dentro de meta para que no se pierda contexto util para agentes.
Este contexto no queda solo almacenado:
scope-gap-analysisdevuelverecommended_next_page, paginas ignoradas por estado archivado y contexto semantico de templates, patrones e integraciones.site-build-planusa la siguiente pagina recomendada para orientar la fase de contenido.site-build-next-steprespeta primero elbuilder_preferencedel item y despues el builder global del proyecto.
{
"sitemap": {
"pages": [
{
"title": "Pricing",
"slug": "pricing",
"purpose": "Convertir early adopters",
"status": "planned",
"role": "conversion",
"owner": "growth",
"builder_preference": "bricks",
"notes": "Mantener la oferta de beta visible",
"meta": {
"campaign": "early-adopter"
}
}
],
"templates": [
{
"name": "Product archive",
"status": "planned",
"role": "commerce",
"owner": "ops",
"builder_preference": "elementor_v4",
"notes": "Usar la version compatible con el sitio activo"
}
]
},
"integrations": [
{
"name": "FluentCart",
"status": "planned",
"role": "checkout",
"owner": "ops",
"notes": "Responsable del checkout y licencias",
"meta": {
"risk": "payments"
}
}
]
}
Empezar desde cero
Planifica un sitio nuevo usando scope.md.
Brief:
[describe negocio, publico, oferta y objetivo]
Primero haz dry_run:
- propone sitemap;
- recomienda plugins;
- indica builder recomendado;
- define componentes globales;
- prepara fases de construccion;
- no escribas scope.md hasta que confirme.
Cuando el plan sea correcto:
Guarda el scope.md con el plan aprobado.
Despues dame el site-build-plan y el primer paso recomendado.
Sitio existente
Importa el scope desde este sitio en dry_run.
Quiero:
- paginas existentes;
- builders detectados;
- plugins instalados;
- capacidades que parecen necesarias;
- gaps frente a un scope completo;
- no escribas nada todavia.
Despues puedes pedir:
Haz gap analysis contra scope.md y propon nuevas paginas, mejoras y configuraciones pendientes.
Exportacion portable
La exportacion no intenta hacer una copia ciega. Genera un contrato portable para reconstruir la web o partes de ella en otro entorno dinamico.
Abilities principales:
| Ability | Para que sirve |
|---|---|
kodavio/site-export-plan | Detectar paginas, builders, formularios, assets y bloqueos. |
kodavio/site-export-page | Exportar una pagina como modelo dinamico portable. |
kodavio/site-export-package | Crear un paquete JSON en dry_run o escribirlo en uploads con confirmacion. |
kodavio/site-static-snapshot-package | Capturar HTML renderizado como snapshot estatico con manifest, rutas, assets y tareas de reconexion. |
Formularios Bricks
La primera fase de exportacion cuida especialmente Bricks Forms:
- detecta nodos de formulario;
- extrae campos;
- normaliza acciones;
- no exporta secretos;
- marca email, redirect y webhooks como tareas de reconexion;
- devuelve warnings si el formulario no es seguro o esta incompleto.
Prompt recomendado:
Prepara exportacion portable de estas paginas.
Primero dry_run:
- ejecuta site-export-plan;
- revisa formularios Bricks;
- dime que se puede exportar;
- marca webhooks, emails y secretos como reconexion manual;
- no escribas package todavia.
Flujo completo
- Leer
scope.md. - Leer
design.md. - Ejecutar
site-export-plan. - Exportar una pagina representativa con
site-export-page. - Revisar formularios y assets.
- Ejecutar
site-export-packageendry_run. - Si todo esta correcto, escribir paquete con
confirm_write=true.
Para una primera salida estatica usable:
- Ejecutar
site-static-snapshot-packagecondry_run=true. - Revisar rutas, estado HTTP, assets y warnings de formularios.
- Si todo encaja, repetir con
dry_run=falseyconfirm_write=true. - Revisar los HTML generados en
uploads/kodavio/static-sites/.
El snapshot estatico conserva referencias externas a CSS, JS e imagenes. No sustituye aun a un generador estatico completo con descarga y reescritura de assets.