Si el botón Publish o Update muestra "Your Cloud Balance is insufficient to publish" o "Your Cloud Balance is insufficient to update", tu billetera Cloud se ha quedado sin fondos.

Para solucionarlo:

1. Ve a Settings > Cloud & AI para revisar tu saldo actual.

2. Selecciona Top up now y agrega fondos a tu billetera Cloud.

3. Vuelve al panel de Publish e inténtalo de nuevo.

Nota: Tu billetera Cloud es independiente de tus créditos de suscripción. La billetera Cloud financia los servicios de hosting y despliegue, mientras que los créditos de suscripción se usan para conversaciones con el agente de IA.

1. Revisa la vista de uso de almacenamiento e identifica los chats, proyectos y archivos más grandes.
2. Descarga o haz una copia de seguridad de cualquier cosa que puedas necesitar más adelante.
3. Elimina solo los elementos innecesarios. Si la eliminación del chat ofrece quitar datos de disco asociados, selecciona esa opción solo después de confirmar que es seguro descartar los datos.
4. Actualiza la página y confirma que el almacenamiento disponible ha aumentado.
5. Vuelve a Publish e inténtalo una vez más.

La eliminación puede ser permanente y puede romper un proyecto que haga referencia a un archivo eliminado. Si el uso no disminuye, contacta con Support con la vista de almacenamiento, el plan, el enlace del proyecto y la hora del fallo al publicar.

Espera a que termine el escaneo de seguridad y luego revisa cada elemento marcado antes de publicar.

1. Selecciona Resolve All e inspecciona el comportamiento afectado. Corrige los problemas relacionados con secretos expuestos, autenticación, permisos, datos de usuario o acceso externo inseguro antes del uso en producción.
2. Si un secreto pudo haber quedado expuesto, elimínalo del proyecto y rótalo a través del proveedor correspondiente antes de publicar.
3. Ejecuta el escaneo nuevamente y verifica el flujo afectado.
4. Usa Publish Anyway solo cuando un revisor responsable entienda y acepte el riesgo restante no crítico. Registra el motivo y evita omitir un riesgo no resuelto en un sitio de producción.

Si no puedes determinar el impacto de un hallazgo, no lo publiques. Contacta con Support o con el responsable de seguridad con el texto del hallazgo y evidencia saneada.

1. Prueba por separado la URL de producción de la plataforma y el dominio personalizado. También compara la página raíz con la página específica o la ruta de API que falla.
2. Registra el código de estado exacto, la URL completa, la hora y la zona horaria, y si el fallo es constante o intermitente.
3. Revisa el estado del despliegue más reciente y si un cambio reciente en dependencias, variables de entorno, Base de datos o servicios externos coincide con el inicio del fallo.
4. Captura los errores relevantes de Console y Network.

Si el fallo continúa, contacta con Support con los pasos para reproducirlo, la versión afectada y diagnósticos saneados. Antes de enviar un HAR, salida de comandos o una captura de pantalla, elimina cookies, encabezados Authorization, tokens, parámetros secretos de consulta, datos personales e información de pago.

Si tu despliegue agota el tiempo de espera o el sitio en vivo no está disponible temporalmente:

1. Verifica si tanto el subdominio Prod de la plataforma como Preview están inaccesibles, o solo uno de ellos.

2. Mantén visible la página de error actual; no hagas clic repetidamente en Publish.

3. Verifica si modificaste recientemente dependencias, puntos de entrada de inicio o conexiones de Base de datos, ya que estos cambios pueden afectar el despliegue.

Si el problema persiste, contacta con Support e incluye:

- Enlace del proyecto y URL en vivo

- Hora del fallo y tu zona horaria

- Número de versión y captura de pantalla de la página de error

- Si Preview funciona normalmente

- Si modificaste recientemente dependencias, entrada de inicio o conexión de Base de datos

Si el panel Publish muestra "latest" con el botón atenuado, o se queda atascado en "Building":

1. No hagas clic repetidamente en Publish; esto no acelerará el proceso y puede crear tareas de compilación duplicadas.

2. Espera unos minutos y actualiza la página.

3. Si el estado no cambia después de actualizar, contacta con Support.

Incluye lo siguiente al contactar con Support:

- Enlace del chat

- Captura de pantalla completa del panel Publish (incluida la URL de la página, el número de versión y el estado del botón)

- Hora de ocurrencia y tu zona horaria

- Número de versión que se muestra actualmente

- En qué paso comenzó a mostrar "Building" o el botón se atenuó

1. Verifica si la imagen falta en Visor de Apps, en el sitio publicado o en ambos lugares.
2. Selecciona Reload App Viewer una vez. Si el problema está solo en el sitio en vivo, confirma que la versión más reciente se haya publicado o actualizado.
3. Indícale al Agente la página, la imagen que debería aparecer y de dónde provenía originalmente la imagen. Pídele que verifique que el proyecto actual siga usando el nombre y la ubicación correctos de la imagen.
4. Si la imagen original fue eliminada o renombrada, vuelve a subir o seleccionar la imagen prevista y luego vuelve a probar la página.
5. Si la imagen usa Almacenamiento de App u otro servicio conectado, confirma que el servicio previsto esté conectado y que el archivo siga existiendo allí.

Si la imagen sigue sin cargar, contacta con Atoms Support con el Chat Link, la URL de la página afectada, el nombre o fuente de la imagen y una captura de pantalla. No incluyas enlaces de acceso privados, contraseñas, claves ni tokens.

Si el paquete exportado para self-host se descarga correctamente pero no se ejecuta:

1. Revisa el README incluido en el paquete de exportación para conocer los requisitos del entorno y los pasos de configuración.

2. Verifica que tu entorno de ejecución coincida con los requisitos (versión del SO, versión de Docker, versión de Node.js).

3. Ejecuta el comando de inicio y revisa la salida completa en busca de mensajes de error.

Si el problema persiste, contacta con Support e incluye:

- Versión de exportación y hora de descarga

- SO en ejecución y versión de Docker

- Comando completo ejecutado y salida completa

- Script o ruta de API que falló

- Método de despliegue esperado

Importante: Adjunta un ejemplo de configuración saneado, pero NO incluyas contraseñas, secretos ni tokens.

Visor de Apps y el sitio publicado muestran distintas etapas de tu proyecto. Guardar un cambio visual no actualiza el sitio en vivo por sí solo.

1. En Design, selecciona Save y espera a que termine la tarea actual del Agente o la compilación.
2. Abre Publish. La publicación usa la versión más reciente del proyecto; no hay selector de versión en el panel Publish.
3. Selecciona Publish para la primera versión o Update para una versión posterior. Espera hasta que el panel muestre Up to date.
4. Abre el sitio en vivo en una pestaña nueva y recárgalo una vez.
5. Si la dirección predeterminada de Atoms muestra el cambio pero un dominio personalizado no, revisa la conexión del dominio en lugar de publicar la misma versión repetidamente.

Si el sitio en vivo sigue mostrando la versión incorrecta, contacta con Atoms Support con el Chat Link, la URL en vivo, la versión que pretendías publicar, la hora y zona horaria, y capturas de pantalla de Visor de Apps y del sitio en vivo.

1. Contén el riesgo inmediato. Si la versión expone datos sensibles o crea un comportamiento inseguro, abre App Status y usa Pause para una app elegible de Nube de Atoms o Unpublish para eliminar el acceso público. Si no hay un riesgo activo, evita causar una interrupción innecesaria.
2. Registra el dominio afectado, la hora de publicación, la versión actual, la versión prevista y el impacto comercial.
3. Después de que se detenga la tarea actual del agente, abre Versions, elige la última versión buena conocida y selecciona Restore this version.
4. Verifica la versión restaurada en Preview, incluidos los flujos críticos de inicio de sesión, pago y datos, y luego publícala o actualízala.

Restaurar una versión del proyecto puede no revertir cambios en la Base de datos de producción ni acciones externas. No sobrescribas ni elimines datos de producción para imitar una reversión. Contacta con Support de inmediato cuando haya datos, credenciales, pagos o cambios destructivos involucrados.

1. Detén o espera a que termine la tarea actual del agente; no se puede restaurar una versión mientras haya trabajo conflictivo activo.
2. Abre Versions, localiza la última versión buena conocida y selecciona Restore this version.
3. Revisa el proyecto restaurado en Preview y prueba los flujos críticos que cambiaron.
4. Publica o actualiza solo después de que el resultado en Preview sea correcto.

La restauración de una versión del proyecto no necesariamente revierte registros de Base de datos de producción, cambios de esquema, variables de entorno, pagos, correos electrónicos u otras acciones externas. Si la versión cambió datos de producción o la versión de destino no está disponible, detente y contacta con Support con ambos números de versión, el dominio afectado y el resultado requerido de preservación de datos.

Pause y Unpublish son dos acciones diferentes:

Pause (solo proyectos de Nube de Atoms):

- La app deja de estar disponible para los visitantes.

- Los recursos del servidor permanecen asignados y la facturación continúa.

- Puedes reanudar la app en cualquier momento desde App Status.

Unpublish (todos los proyectos):

- El sitio web queda completamente fuera de línea. Cualquiera que use la URL publicada pierde el acceso.

- Para proyectos de Nube de Atoms, se liberan los recursos del servidor.

- Puedes volver a publicar el proyecto más adelante, pero los visitantes no podrán acceder hasta que lo hagas.

Usa Pause para una retirada temporal con reinicio rápido. Usa Unpublish para eliminar completamente el sitio.

Si tu navegador muestra "too many redirects" o la página sigue recargándose sin mostrar contenido:

1. Prueba el subdominio Prod predeterminado de la plataforma (no tu dominio personalizado) para determinar si el bucle de redirección se debe a la configuración del dominio o a la propia aplicación.
2. Si el subdominio Prod predeterminado funciona, revisa la configuración DNS de tu dominio personalizado y las reglas de redirección de tu registrador de dominios que puedan entrar en conflicto con la plataforma.
3. Borra la caché del Navegador o prueba en una ventana de incógnito para descartar redirecciones almacenadas en caché.

Si el problema persiste, contacta con Support e incluye:

- URL completa que muestra el bucle de redirección

- Si el subdominio Prod predeterminado es accesible

- Nombre del dominio y proveedor de DNS

- Captura de pantalla completa del error

Si tu app funciona en Preview pero falla en producción debido a variables de entorno faltantes o vacías:

1. Verifica si la variable de entorno se guardó antes o después de la última publicación. Si se guardó después, necesitas publicar de nuevo para que el cambio tenga efecto.
2. Verifica que la variable esté configurada para el entorno correcto (Development vs. Production).
3. Comprueba si el mensaje de error del servicio descendente da alguna pista; por ejemplo, "unauthorized" a menudo significa que una clave de API está vacía o es incorrecta en ese entorno.

Si el problema persiste, contacta con Support e incluye:

- Enlace del proyecto o URL en vivo

- El nombre de la clave afectada y qué entorno tiene el problema

- El error completo del servicio descendente

- Una captura de pantalla saneada de la página de configuración

- Si la configuración se guardó antes o después de publicar

Importante: Proporciona solo nombres de claves. NO envíes valores secretos, contraseñas ni tokens.

Los hallazgos pueden usar una redacción similar mientras apuntan a ubicaciones diferentes. Una redacción similar no significa necesariamente que los resultados sean duplicados.

1. Compara el nombre del hallazgo y la ubicación mostrada para cada resultado.
2. Revisa cada ubicación única en lugar de descartar la redacción repetida.
3. Si varios hallazgos tienen la misma causa subyacente, corrige esa causa y luego vuelve a revisar cada ubicación.
4. Ejecuta nuevamente el escaneo de seguridad en la versión actualizada.

Si el mismo hallazgo y ubicación siguen apareciendo más de una vez, contacta con Atoms Support con el Chat Link, la hora del escaneo y la zona horaria, el número de hallazgos y una captura de pantalla censurada. Elimina cualquier contraseña, clave, token u otra información sensible que pueda aparecer en un hallazgo.

Un escaneo completado sin hallazgos reportados es una comprobación útil, pero no puede garantizar que se hayan encontrado todos los problemas de seguridad o de ejecución. El escaneo revisa la versión seleccionada del proyecto; tu app aún debe probarse de la forma en que los usuarios reales la usarán.

Antes de publicar, prueba los recorridos importantes de tu app, incluidos inicio de sesión, roles de usuario, acceso a datos privados, pagos y servicios conectados. Usa cuentas de prueba separadas para distintos roles y confirma que cada cuenta pueda acceder solo a la información y acciones previstas para ella.

Si descubres un problema en producción que podría exponer cuentas, datos privados, pagos o credenciales, primero deja de usar o restringe el acceso a la función afectada. Rota cualquier credencial que pueda haber quedado expuesta y luego contacta con Atoms Support con el Chat Link, la versión afectada, los pasos para reproducir el problema, la hora y zona horaria, y una captura de pantalla censurada. No compartas la credencial expuesta en sí.

Si el escaneo informa que una acción solo para administradores puede no estar protegida, trata el hallazgo como no resuelto hasta que confirmes que los usuarios no autorizados no pueden usarla. Ocultar un botón de administrador no es suficiente si la acción aún puede solicitarse de otra manera.

1. Abre el hallazgo e identifica la acción o ubicación que menciona.
2. Decide qué roles con sesión iniciada deberían poder usar esa acción.
3. Pídele al Agente que verifique el permiso del usuario cuando se solicite la acción, no solo cuando se muestre el botón.
4. Prueba la acción sin iniciar sesión, con una cuenta de prueba normal y con una cuenta de prueba de administrador autorizada.
5. Confirma que los intentos rechazados no revelen datos privados ni realicen cambios, y luego ejecuta nuevamente el escaneo de seguridad.

No publiques la función afectada si una cuenta no autorizada aún puede usar la acción. Contacta con Atoms Support con el Chat Link, el texto del hallazgo, la versión afectada y una captura de pantalla censurada si no puedes resolverlo.

HTTPS protege la información mientras viaja entre un usuario y un servicio. Si el escaneo informa un problema de HTTPS, usa el hallazgo exacto para identificar la dirección, recurso, callback o configuración de dominio afectados.

1. Abre el hallazgo y anota la ubicación exacta y la dirección que informa.
2. Pídele al Agente que reemplace esa conexión específica por la dirección segura compatible con su proveedor, o que corrija la configuración de dominio relacionada.
3. No ignores advertencias de certificados ni cambies una dirección a ciegas si el servicio externo no documenta un equivalente seguro.
4. Vuelve a probar el recorrido de usuario afectado y confirma que ninguna contraseña, token, detalle de pago o información privada se envíe a través de una conexión insegura.
5. Ejecuta nuevamente el escaneo de seguridad en la versión actualizada.

Si el hallazgo se refiere a un dominio personalizado o certificado que no puedes corregir, contacta con Atoms Support con el Chat Link, la URL afectada, el texto del hallazgo, la hora y zona horaria, y una captura de pantalla censurada.

Row Level Security, o RLS, es una función de Supabase que controla qué filas de la Base de datos puede leer o cambiar cada usuario. Este hallazgo es relevante solo cuando el proyecto usa Supabase y el escaneo identifica una tabla cuyas reglas de acceso necesitan revisión.

1. Abre el hallazgo e identifica la tabla que menciona.
2. Anota quién debería poder ver, agregar, editar o eliminar los datos de esa tabla.
3. Pídele al Agente que cree las políticas de Supabase menos permisivas que admitan esos recorridos de usuario.
4. Prueba sin iniciar sesión y con una cuenta de prueba separada para cada rol. Confirma que cada cuenta pueda acceder solo a las filas y acciones previstas.
5. Ejecuta nuevamente el escaneo de seguridad después de aplicar las políticas.

No desactives RLS ni permitas a todos los usuarios solo para eliminar la advertencia. Antes de hacer un cambio que pueda afectar datos existentes, confirma el plan y conserva una copia de seguridad o exportación segura cuando corresponda. Nunca compartas claves de Supabase ni credenciales de Base de datos en Chat o capturas de pantalla.