Los errores de publicación ahora dicen qué pasó, en palabras sencillas
Cuando una publicación falla en Mythex, el diálogo ahora te dice en una frase clara qué pasó (el build falló, tu app se detuvo justo después de arrancar, tu app nunca arrancó, un archivo es demasiado grande, o algo salió mal de nuestro lado) y ofrece Corregir con IA y Volver a intentar. La salida sin procesar del build y de tu app sigue llegando al agente, así que Corregir con IA puede leerla y arreglar el proyecto, pero ya no tienes que leerla tú.
Qué cambió
Una frase que puedes usar
Cada publicación fallida tiene ahora un tipo, decidido en el momento en que falla a partir de datos que ya tenemos allí (qué paso falló, si la máquina de la app informó de caídas, si llegó a aceptar conexiones), en lugar de leer el texto del error después. Cada tipo tiene su propio mensaje:
| Lo que ves | Qué significa |
|---|---|
| «El build falló.» | El comando de compilación o el Dockerfile de tu proyecto no compiló. |
| «Tu app se detuvo justo después de arrancar.» | Se publicó y luego terminó o siguió reiniciándose. |
| «Tu app no arrancó después de publicar.» | Se publicó pero nunca empezó a aceptar conexiones. |
| «Este archivo es demasiado grande» / demasiados archivos | Un sitio estático supera el límite de tamaño por archivo o de número de archivos. El mensaje enumera los archivos. |
| «Este nombre de enlace no se puede usar para publicar.» | Cambia el nombre del enlace y vuelve a publicar; tu código está bien. |
| «La publicación está ocupada un momento» | Nada va mal en tu app. Vuelve a publicar en unos minutos. |
| «…un problema de nuestro lado, no de tu app.» | Es cosa nuestra. Vuelve a publicar en unos minutos. |
Corregir con IA en cada fallo
Cada fallo muestra Corregir con IA y Volver a intentar. Cuando usas Corregir con IA, el agente recibe el tipo de fallo y la salida completa del build o de la app, de forma privada, en su propio contexto. Si algo en tu app está mal, lo arregla. Si nada lo está (un momento ocupado, o un problema de nuestro lado), puede simplemente volver a publicar. No tienes que averiguar qué tipo de fallo fue.
Problemas después de salir en vivo
Una publicación puede tener éxito y la app fallar unos minutos después. Mythex revisa las apps publicadas con regularidad. Si una app en vivo sigue cayéndose, o sigue en marcha pero deja de aceptar conexiones, la publicación se marca como fallida, recibes un correo y el proyecto muestra el mensaje con Corregir con IA. Lo que imprimió la app se guarda para que lo lea el agente.
Límites de tamaño comprobados antes de subir
En los sitios estáticos, antes de subir nada se comprueban el tamaño de cada archivo y el número total de archivos. Si algo supera el límite, recibes un único mensaje que enumera cada archivo demasiado grande, en lugar de un fallo a mitad de camino.
Por qué lo construimos
Antes, una publicación fallida mostraba lo que hubieran impreso las herramientas detrás de la publicación. En una semana de finales de septiembre, la mayoría de los fallos mostraban textos del constructor que eran cosa nuestra, no de ellos: contactos de facturación, números de versión internos, rutas del registro, errores de almacenamiento. Corregir con IA entonces pegaba ese mismo texto en el chat. Se pedía a la gente que depurara nuestra infraestructura.
Parte de ese texto, además, simplemente era incorrecto. Una app que nunca escuchó en su puerto se reportaba como «un problema de nuestro lado», cuando el arreglo estaba en la app. Un archivo estático por encima del límite de tamaño se reportaba igual, y volver a publicar nunca podía funcionar.
Y cada parte de Mythex que reaccionaba a un fallo (el diálogo, las notificaciones, Corregir con IA, nuestras propias alertas) solía deducir qué había pasado buscando palabras en el texto del error. Eso se rompía cada vez que cambiaba la redacción. Ahora el tipo se registra donde ocurre el fallo, y todo lo demás lee el tipo.
Aplicamos la misma regla a otros errores mientras estábamos:
- Chat. Si la conexión se corta mientras se transmite una respuesta, ahora ves nuestra frase en lugar del «Load failed» o «Failed to fetch» del navegador.
- Dominios propios. Los mensajes sobre comprar o conectar un dominio ahora se eligen según el estado y los códigos de la respuesta, en lugar de reenviar las frases del proveedor de dominios.
- Generación de imágenes. La tarjeta muestra nuestro mensaje; el agente recibe el detalle del servicio.
Cómo usarlo
- Publica como de costumbre desde el botón Publicar.
- Si falla, lee el mensaje de una línea en el diálogo.
- Haz clic en Corregir con IA. El agente lee la salida del build o los logs de tu app, arregla lo que esté mal, y vuelve a publicar si nada de la app necesitaba arreglos.
- O haz clic en Volver a intentar para publicar la misma versión otra vez: la opción correcta para «ocupado un momento» y «un problema de nuestro lado».
- Si el mensaje trata sobre el nombre del enlace, cámbialo antes de volver a publicar. Para cualquier otro error, mantén el mismo nombre.
Límites
- Algunos fallos muestran botones distintos: un nombre de enlace ocupado sugiere otros nombres, y quedarse sin créditos ofrece añadir créditos.
- Los sitios estáticos tienen un límite por archivo de unos 25–30 MB, según el tipo de sitio, y hasta 20.000 archivos. Los archivos grandes es mejor guardarlos en almacenamiento y enlazarlos.
- Las publicaciones fallidas anteriores a este cambio no tienen tipo, así que muestran una línea neutra en lugar de un motivo concreto.
- Si «un problema de nuestro lado» sigue apareciendo, contacta con soporte con el ID del proyecto y el nombre del enlace.
La lista completa de mensajes y qué hacer con cada uno está en solución de problemas de publicación. Si estás arreglando a mano una app difícil, nuestra guía sobre cómo depurar una app creada con IA te guía paso a paso. Y para saber qué pasa con un sitio en vivo mientras lo vuelves a publicar, consulta tu app publicada ahora sigue activa mientras la vuelves a publicar.