Mejorar una app existente

Una vez que tienes un fork, el ciclo natural es el mismo que con cualquier app tuya: fork → edito en el builder → publico → el marketplace muestra mi versión. Esta página describe ese bucle y cuándo conviene forkear de verdad versus intentar contribuir al original.

El bucle fork → editar → publicar

1. Fork

Pulsas Clone en /apps/[id]. Acabas en /builder?app=<tu-nuevo-id> con el código de la app original ya cargado. (Para los detalles ver forkear.)

2. Editar

Dentro del builder, tu fork se comporta como cualquier otra app tuya: hablas con el modelo, ves la vista previa, miras los ficheros en la pestaña files cuando quieres entender qué se generó. Cada iteración se guarda como una versión nueva — el lineage hacia la app original no cambia.

Ideas de cambios típicos que justifican un fork:

Cambiar de idioma o tono — la app está en inglés y la quieres en español, o al revés.
Adaptar al uso propio — los textos genéricos pasan a ser específicos de tu equipo o tu marca.
Combinar dos apps — copias trozos de otro fork tuyo para hacer una versión "kitchen sink".
Probar una hipótesis — quieres ver si un cambio funciona sin tocar la app original (especialmente útil si la original es de otra persona).

3. Publicar

Cuando estás contento con el resultado, pulsas Publish y eliges un slug nuevo. A partir de ahí:

Tu fork aparece en /marketplace como una app más, ordenada por fecha de publicación.
Tu nombre figura como autor de esta versión, sin esconder el origen — la cadena de lineage sigue siendo navegable desde la página de la app.
El creador original puede ver tu fork en la lista de forks directos de su app.

Para el detalle del flujo de publicar ver publicar en el marketplace.

¿Forkear o proponer un cambio?

Si el cambio que tienes en mente probablemente le interesa al creador original (un bug, una traducción que falta, una pequeña mejora de UX), podrías preferir "proponérselo" en vez de mantener tu propio fork indefinidamente. Hoy esa opción no existe dentro de cavioca.

open Pull requests entre forks (el equivalente a abrir un PR en GitHub que el creador original pueda revisar y mergear) está en la lista de cosas a construir, pero no tiene UI, ni endpoint, ni base de datos aún. Mientras tanto:

Forkea y publica tu versión — el lineage deja claro de dónde viene.
Si quieres dar feedback al creador original, su perfil (/u/<username>) suele incluir un canal de contacto, o puedes escribir directamente a [email protected] para casos puente.

Esto no es un compromiso de roadmap: PRs entre apps es un tema abierto a discusión, no algo que vayamos a soltar la semana que viene.

¿Cuándo NO conviene forkear?

Forkear es barato pero no gratis: mantienes tu propia copia y dejas de recibir mejoras del original. Conviene no forkear cuando:

Sólo quieres "echar un vistazo" — la página /apps/[id] ya te deja explorar la versión publicada sin clonarla.
El cambio es algo que tú mismo no vas a mantener — un fork abandonado en el marketplace no le sirve a nadie.
Lo que realmente necesitas es uso privado, no edición. Una app publicada se puede usar tal cual; no hace falta forkearla para abrirla.

Tu fork también es forkable

Cualquier versión publicada por ti — incluido un fork — puede ser forkeada por otra persona. La cadena de lineage se sigue extendiendo: si forkeas A → publicas B, y alguien forkea B → publica C, entonces C es descendiente directo de B y descendiente indirecto de A. Ver atribución y lineage para cómo se muestra esto en la UI.

Sincronizar con el original

deferred "Traer cambios del original al fork" (el equivalente a un git pull desde el upstream) no existe. Si el creador original publica una versión nueva con mejoras que también quieres, hoy tendrías que copiarlas a mano dentro del builder. No es elegante, pero es honesto: una sincronización automática entre apps con código generado por IA es un problema abierto que aún no sabemos resolver bien.