For AI agents: fetch the complete documentation index at /llms.txt, the full documentation corpus at /llms-full.txt, the agent skill at /skill.md, or this page as Markdown at /es/docs/web/updating-the-kit.md (or send Accept: text/markdown).
Actualiza tu copia cuando el kit mejore
Trae las mejoras del repositorio de origen a tu copia — anota tu punto de partida, descarga la nueva revisión, fusiónala en una rama y verifica antes de desplegar.
1. Anota desde dónde partiste
Trata una actualización como un pequeño proyecto, no como un pegado: comparas la revisión del kit que tienes con la más nueva, trasladas los cambios y pruebas en una rama antes de desplegar. Esto funciona tanto si tu proyecto es un fork de un repositorio del kit — una copia que GitHub mantiene conectada al origen — como si es código que copiaste a tu propia aplicación.
Antes que nada, escribe una nota en tu proyecto con tres cosas: el commit del kit desde el que partiste — el SHA, el código corto de Git que identifica una versión exacta — el repositorio que recibiste (supastack-web, supastack-mobile, supastack-desktop o el monorepo All Platforms) y los cambios que ya hiciste por tu cuenta.
Los repositorios del kit y el monorepo tienen historiales distintos, así que nunca fusiones una rama de uno en un fork del otro. Si nunca anotaste un SHA de partida, encuentra la versión compartida más cercana con git merge-base en un fork, o identifica los últimos archivos y pruebas que copiaste en una adopción selectiva — y revisa un diff más amplio cuando la base exacta sea incierta.
2. Descarga y fusiona la nueva revisión
Ejecuta los comandos de abajo en una terminal dentro de la carpeta de tu proyecto, con tu trabajo guardado y confirmado — un árbol de trabajo limpio, para que nada a medias se mezcle en la fusión. Las palabras entre corchetes angulares son plantillas de reemplazo: sustituye tus propios valores en lugar de todo el <thing>. La dirección de GitHub mostrada es un marcador; usa la dirección del repositorio del que hiciste fork.
Qué hace cada línea: git remote add le enseña a tu copia una segunda dirección llamada kit-upstream — el repositorio del kit — y git fetch descarga su estado más reciente sin tocar tus archivos. git switch -c crea una rama de actualización separada para que tu rama principal quede intacta mientras revisas. git log lista los commits que estás a punto de traer y git diff --stat resume qué archivos cambiaron; lee el diff completo de los módulos que usas, no solo los títulos de los commits. git merge trae el código nuevo a la rama de actualización.
Si Git informa de que el remoto kit-upstream ya existe, salta la línea remote add y continúa con git fetch. <previous-kit-sha> es el SHA de partida que anotaste en el paso 1.
# Upstream is the platform repository you forked — substitute its real URL
# (supastack-web shown; use supastack-mobile or supastack-desktop as fits).
git remote add kit-upstream https://github.com/<org>/supastack-web.git
git fetch kit-upstream
git switch -c upgrade/kit-update
git log --oneline <previous-kit-sha>..kit-upstream/main
git diff --stat <previous-kit-sha>..kit-upstream/main
git merge kit-upstream/main3. Resuelve conflictos sin perder tu trabajo
Un conflicto significa que ambos lados cambiaron las mismas líneas: el kit avanzó y tú personalizaste el mismo lugar. Git pausa la fusión y marca el archivo — te está pidiendo elegir, no informando de un daño.
Abre cada archivo marcado en tu editor y decide línea a línea: conserva los textos, nombres y ajustes propios de tu producto, y toma las correcciones y los cambios estructurales del kit. Nunca resuelvas un conflicto reemplazando un archivo que personalizaste con la versión nueva completa del kit — eso borra tu trabajo. Resuelve dentro de la rama de actualización y ejecuta las pruebas de cada área resuelta antes de continuar.
Si la fusión sale mal, git merge --abort devuelve la rama a su estado anterior a la fusión. Nada de este flujo cambia tu rama principal ni tu despliegue hasta que tú mismo fusiones la rama de actualización.
4. Actualiza datos y despliega en el orden correcto
Las nuevas revisiones del kit pueden cambiar la base de datos. Lee los archivos nuevos en packages/db/drizzle/ — la carpeta de migraciones — y haz una copia de seguridad de los datos de producción antes de aplicar migraciones; pruébalas primero contra una copia desechable. Despliega los cambios de esquema compatibles antes que el código que los necesita: si una migración elimina o remodela datos, revertir solo el código de la aplicación no puede restaurar el esquema anterior.
Compara el nuevo .env.example con tus propios ajustes y añade los valores recién requeridos en el panel de tu hosting. Los archivos .env llevan secretos y nunca se confirman en Git — los recreas a mano en cada máquina y despliegue, y se mantienen fuera de los valores NEXT_PUBLIC_ y EXPO_PUBLIC_.
Antes de desplegar, ejecuta las propias verificaciones del kit. En el monorepo All Platforms, corepack pnpm check:local corre lint, typecheck, las pruebas unitarias y una comprobación de formato sin credenciales de pago; corepack pnpm verify:local añade la build de producción y las suites de pruebas de navegador. En un fork de una sola superficie, ejecuta los comandos de prueba y build propios de ese repositorio. Después haz una pasada de humo en staging: inicia sesión, prueba un segundo workspace y recorre el flujo principal de tu producto.
Cuando todo pase, anota el SHA de destino aceptado y los conflictos que resolviste — esa nota es la base de partida para la próxima actualización.
corepack pnpm check:local
# fuller gate: adds the production build and browser suites
corepack pnpm verify:local5. Si copiaste piezas en lugar de hacer fork
Una adopción selectiva — copiar módulos del kit en una aplicación existente — no comparte historial de Git con el kit, así que git merge no puede ayudar. Compara en su lugar el SHA de origen antiguo con el SHA de origen de destino, y traslada solo los cambios que tocan tu parte adoptada.
Revisa como una sola unidad los tipos públicos del módulo, el esquema de persistencia y las migraciones, el llamador del servidor, la configuración, las pruebas y la documentación — un cambio dentro de un paquete puede requerir una ruta o un cambio de entorno correspondiente en otro lugar, y copiar un solo helper puede dejar el resto en un contrato desactualizado. Guarda una nota breve de adaptación — qué archivos del kit tomaste, cuáles saltaste, qué cambiaste — para que la próxima actualización pueda repetir tus decisiones.
Si una actualización rompe algo en tu copia en ejecución, recorre la guía de solución de problemas antes de deshacer tus propios cambios.