Kodavio

Uso diario

Scope y exportacion

Scope y exportacion

Kodavio separa dos memorias complementarias:

MemoriaResponde aUso principal
design.mdComo debe verse el sitio.Tokens, componentes, tipografia, spacing, estilos y sistema visual.
scope.mdQue 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:

AbilityPara que sirve
kodavio/scope-readLeer scope.md estructurado.
kodavio/scope-writeGuardar o fusionar cambios en scope.md.
kodavio/scope-import-from-siteCrear scope desde el sitio actual.
kodavio/scope-plan-new-sitePlanificar un sitio desde un brief.
kodavio/scope-gap-analysisComparar scope con el sitio real.
kodavio/site-build-planObtener plan por fases.
kodavio/site-build-next-stepSaber 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 ejemplo planned, draft, live o archived.
  • 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-analysis devuelve recommended_next_page, paginas ignoradas por estado archivado y contexto semantico de templates, patrones e integraciones.
  • site-build-plan usa la siguiente pagina recomendada para orientar la fase de contenido.
  • site-build-next-step respeta primero el builder_preference del 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:

AbilityPara que sirve
kodavio/site-export-planDetectar paginas, builders, formularios, assets y bloqueos.
kodavio/site-export-pageExportar una pagina como modelo dinamico portable.
kodavio/site-export-packageCrear un paquete JSON en dry_run o escribirlo en uploads con confirmacion.
kodavio/site-static-snapshot-packageCapturar 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

  1. Leer scope.md.
  2. Leer design.md.
  3. Ejecutar site-export-plan.
  4. Exportar una pagina representativa con site-export-page.
  5. Revisar formularios y assets.
  6. Ejecutar site-export-package en dry_run.
  7. Si todo esta correcto, escribir paquete con confirm_write=true.

Para una primera salida estatica usable:

  1. Ejecutar site-static-snapshot-package con dry_run=true.
  2. Revisar rutas, estado HTTP, assets y warnings de formularios.
  3. Si todo encaja, repetir con dry_run=false y confirm_write=true.
  4. 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.

Previous
Sistema de diseño