cavioca

Editar y previsualizar

5 min

Editar y previsualizar

El builder está diseñado alrededor de un único bucle:

editar (con un prompt o a mano) → previsualizar → guardar versión.

Esa secuencia ocurre de forma automática cada vez que el modelo termina de generar, así que la mayoría del tiempo no tienes que pensar en ella. Esta página explica qué pasa por debajo y cómo controlarla cuando lo necesitas: rollback, comparación entre versiones y export.

El bucle, por dentro

1. Editar

Hay dos formas de tocar ficheros:

  • Por prompt — el modelo recibe tu mensaje, decide qué ficheros cambiar y emite un evento file por cada uno. El builder los aplica al store según llegan.
  • A mano stub — el editor de la pestaña files permitirá edición libre próximamente. Hoy la edición a mano se pierde en cuanto el modelo vuelve a generar; trátala como exploración, no como persistencia.

Cada cambio aplicado por el modelo va a un rollback stack interno. Si cancelas la generación a medias, ese stack se deshace y vuelves al estado anterior — no quedan ficheros zombi.

2. Previsualizar

La pestaña preview ensambla los ficheros del store en un HTML inyectado a una iframe. Reacciona a tres fuentes:

  • Cambios del store en directo (mientras la generación escribe).
  • El estado completo cuando la generación termina.
  • Un overlay cuando estás previsualizando una iteración antigua (ver más abajo).

El punto de la cabecera te dice en qué modo estás:

  • verde, parpadeando — live, lo que ves es el último estado real.
  • naranja, fijo — preview, estás mirando una versión vieja, sin modificar el estado actual.

3. Guardar versión

Al terminar la generación, el builder hace un POST a /api/apps/<id>/iterations con todos los ficheros, el resumen (primeros 2 000 caracteres del prompt) y el parent_iteration_id. La respuesta vuelve con un id que pasa a ser el activeIterationId y aparece arriba del todo en history.

El indicador saved 12s ago de la cabecera es exactamente este evento. Si lo ves quedarse en saving…, es que la petición está tardando o ha fallado — refresca la pestaña history para confirmar.

No hay guardado manual. Cada iteración del modelo crea una versión; ese es el modelo mental. Si quieres "puntos de control" más granulares, divide tus prompts en pasos más pequeños.

Versiones e historial

Cada iteración guardada queda en history con:

  • número (v1, v2, …) calculado por orden cronológico,
  • resumen del prompt,
  • timestamp,
  • conteo de ficheros,
  • parent iteration — la versión sobre la que se construyó (lo usa el modelo para entender el contexto en el siguiente turno).

Comparar dos versiones stub

Hoy el flujo es: preview sobre una versión vieja, mira lo que querías comparar, exit y vuelves al estado actual. Una vista diff explícita entre dos iteraciones llegará más adelante.

Restaurar

restore copia los ficheros de una iteración antigua al store y crea una iteración nueva con summary = "restored from <id>". No es destructivo: la versión "abandonada" sigue en el historial y puedes volver a ella.

Casos típicos:

  • "Esto va por mal camino, vuelvo a v3 y reintento desde ahí".
  • "Quería las dos cosas de v5 pero no el rediseño de v6 — restauro v5 y vuelvo a pedir lo único bueno de v6".

Export

export descarga un .zip con la versión seleccionada:

my-app-3f8a2b1c.zip
├── _meta.json         ← id, parent, generation_id, summary, fechas
├── _conversation.md   ← transcripción del chat (user + assistant)
└── files/
    ├── index.html
    ├── styles.css
    └── ...

Es útil para archivar antes de hacer un cambio grande, para compartir una versión concreta con alguien, o para abrir los ficheros en tu editor favorito y trastear localmente.

Rollback automático cuando algo falla

Cuando una generación se cancela o explota a mitad, el builder:

  1. Recorre el rollback stack en orden inverso.
  2. Para cada fichero, si antes no existía, lo elimina; si existía, restaura el contenido previo.
  3. Marca el mensaje del asistente como (cancelled) o muestra el error con un botón try again.

Lo que esto significa para ti: cancelar es seguro. No vas a quedarte con medio carrito generado y medio fichero antiguo incompatible — o sale entero, o vuelve al estado anterior.

Recomendaciones prácticas

  • Iteraciones pequeñas se restauran mejor. Si cada prompt cambia cinco cosas, deshacer "esa última idea" implica perder otras cuatro.
  • Da nombre a la app pronto. El campo de nombre se incluye en los exports (my-app-…zip) y en la URL final tras publicar.
  • No esperes a publicar para probar. El preview es la app real — si funciona ahí, funcionará en cavioca.com/a/<id>.

Siguientes pasos